Month: June 2014
Yeah, simply replying does nothing. You have three options:
- You can go to the blog and edit the original post because you are an author. SO you can just add stuff to the end, or whatever you want.
- You can go to the blog and post a comment to the orginal post.
- You can email me a comment and cc mik110.ts06@blogger.com almost as an afterthought. It will get sent to the blog as a new post – like I have with this post.
#1 gives you the most flexibility, but #3 is the easiest.
I think we should not re-visit using the Nordic. It's decided until we hit a snag. I'll make the code work (pissing and moaning every step of the way, no doubt) but I see no reason why it won't work… yet. If we can make it work we will have a neat device. The FCC certification seems like a good thing to have, so modules seem like a great first iteration.
Don't bother looking at the LCD stuff. It's just not worth the effort. I really wouldn't bust any guts to put extra buttons and switched on the board. I'm pretty sure I can figure some way around. After all, it only has to work once, and then I'll start hacking the code to provide feedback in the way we want anyway, I won't have all those demo messages.
As for the boot selection switches – I don't even know what you are talking about, which shows how much homework I have done. Give me a pointer.
//Mik
On Mon, Jun 23, 2014 at 7:33 AM, David Carkeek <dcarkeek@gmail.com> wrote:
What happens when I reply to "blogger" like I did yesterday? I think it goes into a bit bucket. This is what I wrote yesterday morning.The RayTac board is simply the Nordic chip with a Crystal and some decoupling capacitors on it and then the RF components and an antenna. If the code works on the Nordic board it will work on the RayTac board. So the next step is really to get the DW code to work on the Nordic eval board. However, if it will be too difficult to get the code to work on the Nordic chip, then we can look at putting the ST microcontroller on the Dewbly board. One reason for using a module is that it's already FCC certified. But at this point that's really not very important. On the other hand, eventually it will have to work with some kind of Bluetooth SOC if it's going to be really small. So if we spend a lot of time getting it to work with an ST microcontroller then some of that effort might be wasted.If you need buttons and a display, then we can have some kind of plug-in board with buttons and a display on it that you can use during debugging. There only needs to be enough room for a connector with enough pens on it. That could be combined with the jay tag connector. I won't know how much room there is for that until we start the board layout, but it should be possible to have something. I haven't looked at how the LCD display is driven on the DW eval board.But now I looked at the EVB schematic and see that the LCD display is on SPI: just MOSI, SCK and Select. There are two other pins, RW and SS. I will have to get the LCD datasheet to see what they do.What about the boot selection switches? Will these be needed (for debugging on the initial board)?On Sun, Jun 22, 2014 at 9:58 AM, David Carkeek <dcarkeek@gmail.com> wrote:The RayTac board is simply the Nordic chip with a Crystal and some decoupling capacitors on it and then the RF components and an antenna. If the code works on the Nordic board it will work on the Raytech board. So the next step is really to get the DW code to work on the Nordic eval board. However, if it will be too difficult to get the code to work on the Nordic chip, then we can look at putting the ST microcontroller on the Dewbly board. One reason for using a module is that it's already FCC certified. But at this point that's really not very important. On the other hand, eventually it will have to work with some kind of Bluetooth SOC if it's going to be really small. So if we spend a lot of time getting it to work with an ST microcontroller then some of that effort might be wasted.If you need buttons and a display, then we can have some kind of plug-in board with buttons and a display on it that you can use during debugging. There only needs to be enough room for a connector with enough pens on it. That could be combined with the jay tag connector. I won't know how much room there is for that until we start the board layout, but it should be possible to have something. I haven't looked at how the LCD display is driven on the DW eval board.On Jun 22, 2014, at 2:41 AM, Blogger <no-reply@blogger.com> wrote:I started looking through the DW code. It looks pretty well written and reasonably documented. However it is going to take me quite a few man-days to get into all the corners and figure out how it all works. So my first step is to configure eclipse so that I can compile, load and run their demo code on the STM32F10x. This process is fairly well documented too.The next step might seem to be to port their demo code to whatever BLE chip we use (Lets assume RayTac). It looks straightforward in principle. I'm really not sure how to connect the DW eval kit to the RayTac, or even if this is feasible, but I'll need a lot of DC help to do that. Even so much of the ancillary code assumes access to buttons and LCD. This code will have to be unpicked, and I'll have to find some other way to display their feedback messages, and somehow do without buttons. I'm hoping I can use the SWD channel I have tried so hard to get working. Of course the standard C config will be different for the RayTac chip (at least in some minor ways), so I'm sure that there will be anomalies that I'll have to sort out there too.I said the next step seems to be to port their code to the RayTac. But it would be a smaller step if I could attach the DW rig to the Nordic eval board I just received from Nordic. It will mean changing the DW code to use the right SPI pins, but it has lights and buttons that I know how to use already, and I have it configured to use the SWD channel for debugging messages. That small step would allow me to figure out the differences between the STM32F10x processor and a BLE processor without changing more than I have to. Again though, I'm not sure the DW eval kit can be connected to the Nordic EK, and I'd need a lot of help from DC to figure this out.I'm not really sure what the following step will be. It might be logical to move code onto our hardware, but there's a lot to be said for starting to write our own app (the one that uses both BLE and DW) on the Noridc+DW eval hardware – making sure that it all works in some way, before leaping off onto the TS06 Dewbly. I think a lot depends on when the h/w shows up, and how hard it is to do the previous steps. I like small steps!I notice that DW assumes that it can get access to the SPI for extended periods without being interrupted. This might cause some issues.
//Mik
—
Posted By Blogger to TS06 "Dewbly" at 6/22/2014 02:41:00 AM
I started looking through the DW code. It looks pretty well written and reasonably documented. However it is going to take me quite a few man-days to get into all the corners and figure out how it all works. So my first step is to configure Eclipse so that I can compile, load and run their demo code on the STM32F10x they use for the eval kit. This process is fairly well documented too.
The next step might seem to be to port their demo code to whatever BLE chip we use (Lets assume RayTac). It looks straightforward in principle. I’m really not sure how to connect the DW eval kit to the RayTac, or even if this is feasible, but I’ll need a lot of your help to do that. Even so much of the ancillary code assumes access to buttons and LCD. This code will have to be unpicked, and I’ll have to find some other way to display their feedback messages, and somehow do without buttons. I’m hoping I can use the SWD channel I have tried so hard to get working. Of course the standard C config will be different for the RayTac chip (at least in some minor ways), so I’m sure that there will be anomalies that I’ll have to sort out there too.
I said the next step seems to be to port their code to the RayTac, but now I have written down the process I’m rethinking. It would be a smaller step if I could attach the DW EK to the eval board I just received from Nordic. It will mean changing the DW code to use the correct SPI pins, but the Nordic has lights and buttons that I know how to use already, and I have it configured to use the SWD channel for debugging messages. That small step would allow me to figure out the differences between the STM32F10x processor and a BLE processor without changing more than I have to. Again though, I’m not sure the DW eval kit can be connected to the Nordic EK, and I’d need a lot of help from you to figure this out.
I’m not really sure what the following step will be. It might be logical to move code onto our hardware, but there’s a lot to be said for starting to write our own app (the one that uses both BLE and DW) on the Noridc+DW eval hardware – making sure that it all works in some way, before leaping off onto the TS06 Dewbly. I think a lot depends on precisely when our h/w shows up, and how hard it is to do the previous steps. I like small steps! But I have plenty to keep me busy.
I notice that DW assumes that it can get access to the SPI for extended periods without being interrupted. This might cause some issues.
The replacement boards arrived today. This is version 2.2.0 as opposed to 1.0, so it ought to be more in line with the software.
They also sent a vattery, and five bare nrf51822 chips, so we don’t have to buy any initially. Shall I put them in an envelope and post them to you?
http://quantifiedself.com/2014/06/anne-wright-data-aggregation-exploratio/
Fluxstream is a great next step for the world (and probably Apple). Gather all the data you can from everywhere you can and simple build tools that try to make sense of it. We should consider plugging into these systems to see if they do a good job.
I think there are two power requirements:
1) need to predict if/when power is about to run out, so I can pack my bags;
2) need to measure DW power bursts.
Counting coulombs isn’t really a requirement. And in some senses having a calibrated measurement like Coulombs isn’t a requirement either, because I just need to know that improvements to the code are heading in the right direction power-wise.
The other longer term requirement would be to give the user some idea of how much longer the battery will last – another hour, another day, another few days…
I’m saying this because there is always the assumption that the solar cell will not see light, and the “battery” really will go flat.
//Mik
On Wed, Jun 11, 2014 at 8:05 PM, David Carkeek <dcarkeek@gmail.com> wrote:
The only option I can see at this point for using with a solar cell is the LTC3805. Maybe the TI chip could be used but the LTC specs are a little better. I still need to be sure all the voltages can be supplied using it.
I wonder if we really need the coulomb counter. If there’s room well use it but if not – it might be a candidate for removal. To study power consumption replacing the battery with a large cap charged to a known voltage will be more accurate. The sample rate of the coulomb counter might not be high enough to catch the short power bursts of the DW1000 accurately.
Sent from my iPhone
C:Program Files (x86)Nordic Semiconductornrf51binnrfjprog
I think I may have discovered the issue with the Nordic stuff. Our boards have older revs. of the chip. The dongle is at least two whole versions out of date. So it doesn’t seem like I’m going to get this working without quite a lot of essentially useless effort. I think I may have to buy another eval kit if they don’t send me one soon.
I think I may have discovered the issue with the Nordic stuff. Our boards have older revs. of the chip. The dongle is at least two whole versions out of date. So it doesn’t seem like I’m going to get this working without quite a lot of essentially useless effort. I think I may have to buy another eval kit if they don’t send me one soon.
Finally a response from Nordic.
Hi Mik,
I requested an update internally, and it seems that we have an issue with our eval-kit delivery from our supplier. It was supposed to ship last week, but has been delayed. I am very sorry for this, and I will keep you updated once I hear something.
Regarding the PCA10000:If you have programmed it with the MCP firmware, the whole flash has been readback/flash protected (so that you do not flash it by mistake from Keil for instance). Try calling “nrfjprog -e” from cmd.exe, then flash it from Keil.
Best regardsHåkon
So it appears that they protect the dongle from being overwritten by someone loading code into it, when they meant to load the code into the PCA10001. I found the program Hakon refers to and ran it and hey presto! But not quite. It turns out that the V1 boards are different to the V2 boards now in service, and they are using different serial pins.
So I had to modify one of the header files. I wonder how many other people have been screwed by this. Not too many I guess otherwise they would have fixed the code.
/* Copyright (c) 2012 Nordic Semiconductor. All Rights Reserved.
*
* The information contained herein is property of Nordic Semiconductor ASA.
* Terms and conditions of usage are described in detail in NORDIC
* SEMICONDUCTOR STANDARD SOFTWARE LICENSE AGREEMENT.
*
* Licensees are granted free, non-transferable use of the information. NO
* WARRANTY of ANY KIND is provided. This heading must NOT be removed from
* the file.
*
*/
#ifndef PCA10000_H
#define PCA10000_H
#define HWFC true
// Definitions for PCA10000 v2.0.0
#ifndef BOARD_PCA10000v1
//#warning “Board PCA10000 v2.0.0”
#define RX_PIN_NUMBER 11
#define TX_PIN_NUMBER 9
#define CTS_PIN_NUMBER 10
#define RTS_PIN_NUMBER 8
// Definitions for PCA10000 v1.0
#else
#warning “Board PCA10000 v1.0.0”
#define RX_PIN_NUMBER 3
#define TX_PIN_NUMBER 1
#define CTS_PIN_NUMBER 2
#define RTS_PIN_NUMBER 0
#endif
#endif
Before I left SF I think I blew up one of my Bluetooth development boards – one of the two that David and I actually got as a freebie from Nordic Semiconductor at one of the trade shows we went to. I have been struggling with it and corresponding with Nordic to see how to fix it. Eventually I wrote and told them I was pretty sure it was dead. I sent them this clip from Monty Python which seemed appropriate – if you have never seen it then it is required viewing for British Humor 101.
My charm offensive worked. Today I got this email.
Hi Michael,
It’s been a while since I’ve seen that clip. Fanstastic stuff!
Could you give me your address and phone number (DHL requirement), so I can send you a replacement kit?Best regards
Håkon
//Mik
Two new ideas provoked by this. Korner – Home Security
First idea is that our anchors could provide burglar alarm functionality and be attached to the windows where they can suck energy from the light, and heat.
Second idea, (no biggie) is there some way we could add an ethernet board that was powered from the router?
It’s been a struggle to get everything set up, but at last the mighting program that blinks LEDs and outputs a debug message to the debugger window seems to be working.
 |
| The mighty ‘blinky’ test program |
 |
| A breakpoint has been hit, and the variable ‘count’ is selected for display |
 |
| The trace statement is output to a special debugger window |