Month: April 2015

SDK 8.0.0

Posted on by crackingcontraptions_3voi0v
Recall that Nordic has a “soft-machine” that runs in high memory that provides the BLE functionality.  That eats up a bunch of memory, and our application has to make do with what’s left over.  The application uses a Nordic API that knows where all the entry points to the SM are located in memory.  So the SDK API and the SM are a matched pair.

I have been writing code using SDK V6.1.0.0 without a soft machine loaded because my code has not used BLE yet.  
While I was in SB I got a couple of hours to futz around with TS06.2, and thought I’d pursue the BLE thread a bit.  If the ranging works then I’ll want to write the ranges to the cloud somehow, and it makes sense to use some kind of BLE transport mechansim to do that.  So I thought I’d make a really dumb BLE program that emulated a serial port connection.  Ha!!

Since I last installed the Nordic devkit it has gone through two major releases.  V6 is now V8.  In particular the BLE soft-machine that you load into high memory has moved on too.  Indeed I can’t actually find a matching soft-machine any longer.  So I pretty much have to upgrade the SDK.
SDK 8 codebase is organised quite differently, so I’m glad I didn’t have any BLE code to port across.  On the other hand, there are no instruction for installing V8 under eclipse.  So I made my best attempt and hey presto, none of my programs work under V8.  
So it looks like I have another diversion to work around.


//Mik

TS06.2 Connections and testing

Posted on by crackingcontraptions_3voi0v

The pin connection spreadsheet is here.

I think it should look like this.

Test program


  1. Go to the TESTING directory
  2. If you don’t have it installed already, download and install JFlashLite_V485a.zip
  3. Download the test program TS06_CHECKOUT_C_nRF51822.hex
  4. The UI to JFlashLite is tedious but easy.  Make sure to specify the correct processor using the pull-down menu.
  5. The program should start automatically, but if it doesn’t, then power-cycle. 

OutputThe program loops performing the following 4 tests:

  1.  All the LEDs should come on for 3 seconds.  N.B. LED on pin 0 marked ‘X’ in the photo, is broken on my board, and should be on.
  2. It tries to access the DW chip, and get the chip ID.  If it suceeds it “floods” the LEDs till they are all on in a clockwise direction
  3. It tries to read the DW temp, and battery gauge.  If it suceeds it “un-floods” the LEDs till they are all OFF in a counter-clockwise direction.
  4. The it tries to prime the transmit buffer with test data,  If this works it sets the bottom TWO LEDs
  5. Then it tries to issue a ‘transmit’ command.  If this works then the bottom FOUR LEDs are set.
  6. If the transmission finishes and an interrupt is raised then it sets the bottom SIX LEDs.
  7. To signal the end of the test it ripples the LEDs to and fro 5 times.

Then it returns to step #1

    For discussion – next steps

    Posted on by crackingcontraptions_3voi0v

    TS06.3

    Goals in priority order

    • Establish our process for board replication. That, by itself, is plenty of work, and a lot of unknowns.
    • Evaluate alternative components for TS06.4 

    Steps

    I’m all for keeping the TS06.3 iteration simple. I propose we only fix immediate shortcomings, so we can focus energy on setting up our production process.

    1. Clean up what we have right now – pin assignments, leds, connectors, jumpers.
    2. Not add any new functionality that demands extra software, because I think we will iterate on the h/w again before I have ranging, BLE uploads, and simple PC data display working.
    3. The exception to the above is, maybe to provide hooks so we can measure power consumption, or you can explore power supply/energy harvesting
    4. Decide on our board design/production process, so we can bang out new boards quickly, and confidently. Would a reasonable target be to go from proposed change to flashing the board in under a month?
    5. Replicate a few more (N~8) units for us both to play around with.

    Other things to discuss

    • Smaller? Only to go smaller if it just happens as a result of cleanup, not to make it a goal?
    • Enclosure?  None?
    • Experiment with a less clunky JLINK connector. e.g. Plug-of-nails?
    • Above connector externalizes POW, GND, I2C, USART, 2nd SPI to allow for hacky pre-TS06.4 experiments
    • Remove most of the jumper connections – especially around the DW which doesn’t really need them. Maybe only scratch-able/solderable links?
    • PSU – do we need to experiment with anything?
    • Support for DC’s energy-harvesting experiments?
    • Provide battery option to allow for quick-and-dirty ranging experiments. Could we use a USB battery pack if the USB connector was different?
    • Colored LEDs on unused Nordic pins?

    TS06.4

    I’m optimistically calling this 6.4, but there might be other iterations required before we get here. It just here to set a context for discussing TS06.3

    Goals in priority order

    1. Power management – enhancements to drive down power usage, and simplify the user’s recharging experience.
    2. More data storage (this may be #1)
    3. Another step down in size towards wear-ability.
    4. Experiment with potential enclosures
    5. IMU

    TS06.5

    The first version we try to wear for extended experiments.

    Day #220 – Trying out a few more simple things

    Posted on by crackingcontraptions_3voi0v

    Temp and Voltage

    Temp = 87.01. Volts = 3.01
    Temp = 88.14. Volts = 3.00
    Temp = 87.01. Volts = 3.00
    Temp = 87.01. Volts = 3.00
    Temp = 88.14. Volts = 3.01
    Temp = 88.14. Volts = 3.01
    Temp = 88.14. Volts = 3.00
    Temp = 88.14. Volts = 3.00
    Temp = 88.14. Volts = 3.01
    Temp = 87.01. Volts = 3.00
    Temp = 87.01. Volts = 3.01
    Temp = 88.14. Volts = 3.00
    Temp = 88.14. Volts = 3.00
    Temp = 88.14. Volts = 3.00
    Temp = 87.01. Volts = 3.00
    Temp = 88.14. Volts = 3.00
    Temp = 88.14. Volts = 3.00

    Write a short data packet

    I think I may be transmitting a short text packet, but I have no way of knowing if it is really going into the ether.

    Day #220 – Compiled the DW API

    Posted on by crackingcontraptions_3voi0v

    Today I manged to compile the DW API, and ran a couple of simple test programs.  

    One uses the API to check that the DW module is awake, and is the correct version.  It replied:

    SEGGER J-Link GDB Server V4.98b – Terminal output channel
    deca0130  <-  this is good!

    The second test attempted to flash the LEDS connected to the DW module.

    This example uses a dumb two-line test program using just a bit of Nordic library, and some DW library.  The code size is:

    arm-none-eabi-size –format=berkeley “SPI_to_DW_C_nRF51822.elf”
       text   data    bss    dec    hex filename
      52728   2552    768  56048   daf0 SPI_to_DW_C_nRF51822.elf

    How to interpret the size data

    text is the size of the code in flash.
    data is the amount of initialized data. It also lives in flash.
    bss is where all the variable data lives which is RAM.

    So I already have used about 55K of 256K of flash and 0.75K of 16K of RAM.  However the BLE softmachine is not loaded and that consumes 88K flash and 8K RAM.

    So the current freeboard is:

    Flash: 256-(88+55) =  113K
    RAM: 16-(8+0.75) = 7.25K  — fortunately there is a 32K version

    Day #219 – port of SPI code

    Posted on by crackingcontraptions_3voi0v

    Yesterday I managed to prove I could both read and write to the DW.  My code uses an interrupt routine, so that, in theory anyway, the processor can be doing other stuff while the transfer is in progress.  This may prove to be a small gain, and in any case I discovered that DW do not use interrupt-driven SPI.  Indeed they implement a mutex that turns off interrupts from the DW module while the transfer is in progress, which I’m curious about.

    The other snag is that their SPI routine transfers the command, and data bytes in separate buffers.  I could rewrite my interrupt routine to match their calling protocol, but that’s going to be a bit fiddly and will undoubtedly introduce some bugs.  So I decided to simply copy the two chunks of DW data into a separate buffer, and call my usual one-buffer routine.  I did that getting it to work at all is higher priority, and I can rewrite it later to save the extra buffer space.
    OK, so the next step is to port a little more code over and see if it can drive the DW through my SPI routines.

    Re: Another diversion

    Posted on by crackingcontraptions_3voi0v

    David: 

     

    Remember that Nordic have released their version with 32K RAM and Ray-Tac have sample modules available. Do we want to order some?
    And if we order more modules so we want to get some of the nano versions which are much smaller? But the nano version doesn't have an antenna. I think the idea is to use a PCB antenna, so to do any RF stuff we have to lay out a board.
    Speaking of laying out a board, we can do that as soon as we have module connections that we know will work. I think we're getting close to it.

    Mik:
    I think RAM may be a problem, but I reckon we will run out of program space before we run out of RAM.   I wouldn't bother getting any new modules until we get closer to running into the problem because there may be even better options available by then.  

    As for going smaller: I think we should just go with the modules we have.  They work.  I think our priority is getting the ranging software to work.  If and when it does work, then we will have software that can serve two purposes in the next round of hardware:
    1. We can checkout the new hardware (instead of trying to debug possibly flaky hardware with possibly flaky software)
    2. We can create some ranging benchmarks against which to measure our own antenna designs.

    Module connections:   Here is what I know about the connections  ( see blue box)

    Summary:
    • Some of the DW pins that we have connected to GPIOs are not needed. I think they can float or be be tied hi/lo to save leakage.
    • The DW SPI and IRQ lines can be connected to any pins that make layout easy – it just means changing a defined constant for me.  I have made suggestions.  
    • I don't yet know is RSTn is actually required – I would suggest connecting it via a jumper.  It can probably be tied hi/low?

    //Mik

    On Mon, Apr 13, 2015 at 10:36 PM, David Carkeek <dcarkeek@gmail.com> wrote:

    I can't imagine going through all that. How do you do it? 

    Remember that Nordic have released their version with 32K RAM and Ray-Tac have sample modules available. Do we want to order some?
    And if we order more modules so we want to get some of the nano versions which are much smaller? But the nano version doesn't have an antenna. I think the idea is to use a PCB antenna, so to do any RF stuff we have to lay out a board.
    Speaking of laying out a board, we can do that as soon as we have module connections that we know will work. I think we're getting close to it.

    On Mon, Apr 13, 2015 at 10:06 AM, Mik Lamming <mik@lamming.com> wrote:

    You might wonder what the hell I have been doing all this week.  

    I think we can confidently predict TS06 will run out of program space early.  
    It has to have BLE drivers, and DW drivers as well as all the other sensor stuff, and analysis software.  While we wait for a Nordic processor with more memory I will probably have to partition the code development – i.e. develop and test parts of the code independently, and finally cherry-pick and squeeze bits of code to make the TS06.  (Of course, the BeSpoon module has the advantage that a lot of the code that is outside the DecaWave module is inside the BeSpoon module, but who knows if BeSpoon will last much longer?) 
    I tried partitioning thing with TS02..5.  But the toolkit was more primitive and made it hard to share code between different independent threads of development.  For example, I had a code base that was designed to explore and test the hardware, and another for the networking, and another that integrated parts of the others to make TS.  But it was so hard to partition the code between the two different applications, and back it up each night.  Fortunately the Atmel 256K processor came along, and so I was able to do everything in one module with some squeezing.  Indeed the final code base for TS05 is actually called HWTest rather than TS!  So the code contains a lot of stuff that isn't really needed, and of course soaks up valuable memory.
    I already have several threads going that I am trying to keep separate for simplicity and speed.  But keeping all the source libraries (DW, Nordic) separate and shareable took some more study, and created it's own snags.   Also I will need to keep DW and BeSpoon developments separate.  Then I need to be able to keep the developments for each board definitions separate.
    So organizing the development tools has taken way more time than I ever thought possible – exacerbated by my own ignorance.
    I think I have it kind of organised now, but time will tell.  I'm also backing it up to a git repository so I can move the code base between desktop, and laptop in anticipation of going to the UK.
    It is truly amazing how much time this kind of stuff soaks up.

    Day #217 – SPI to DecaWave working

    Posted on by crackingcontraptions_3voi0v
    The Nordic is talking to the DW module.   I had a few false starts at getting the pin assignments correct.  I seem to have word-blindness where schematics are concerned!  I ended up laboriously tracing the wiring to make quite sure I had it right, and even then I got it wrong… but after two attempts, it seems like it has to be working.
    The manual says that if I read from register 0 I should get to see the Device ID which ought to be in the format:  RIDTAG, MODEL, VERSION, REVISION.   According to the manual I should see the following:  0xDECA, 0x01, 0x3, 0x0.
    The bytes are sent in reverse order for some reason I have yet to fathom, but at least it is talking.  Yay!

    Re: Module connections

    Posted on by crackingcontraptions_3voi0v
    I should be able to answer that question with more than speculative comments in a few days.

    Today I plan to do two things.  

    1. Port my SPI code from the Nordic board to TS06 and see if I can find the relevant SPI pins to create a loop back so I can test the code, and the interrupts are working.
    2. If that is successful, then I plan to locate the Nordic GPIOs that are connected to the DW and re-target the SPI code to talk to it.  Your schematic should be very helpful there thanks.  My goal is to the DW to utter something meaningful back on the SPI – like the chip version number or something that I can verify is correct.  I imagine the challenge will begetting all the SPI protocols set up just right, and it wouldn't surprise me if that took a few days.
    Obviously if I can't get any response out of the DW then I'll reconfigure the connections with jumpers until I fo get some response, and then I can report.
    Any news about the DW kit?

    //Mik

    On Sun, Apr 12, 2015 at 11:35 PM, David Carkeek <dcarkeek@gmail.com> wrote:

    Some time in the not-so-distant past you asked about connections from the BLE module to the DW module. From a board perspective it doesn't seem to matter much. Have a look at the attached schematic to see if there are programming concerns.