TrackerTwo
done (for now)... live GPS tracking, with heath and environment metrics. Tracking heart rate, core body temperature, blood sugar, air temperature and humidity.
A CoreTemp sensor is providing the body temperature, a GlucoRx Aidex sensor for the blood sugar, and based on a RAK 5010 for the main board. (See the previous post for the blood sugar project).
So finally have the reworked GPS tracker up and running, after way too many weeks of coding, tweaking and debugging. Whilst the nRF52 has been really impressive to work with and the SDK is comprehensive with loads of features that are easy to enable, there have been many heffalump traps along the way....
A Core sensor, with some of the blood sensors tried "on the bench" |
But why
Grumbles
It's easy to criticise and moan... so I won't (much), because - creating a good API is hard, and when you have multiple versions of API's that need to be backward compatible for multiple versions of hardware that each also have multiple revisions, that gets very hard. and on the whole, the nRF SDK *is* very good...
but even so, using the SDK has been very frustrating, thankfully there is a huge amount of information and help online, so it's generally just a matter of tracking down enough FAQ's and forum posts discussing whatever problem you're having.
Case in point... there are often three versions of each API, a "legacy" version, a new version and a new new version, or one with DMA support... (e.g. nfrxuart, nfrxuarte, uart, uart_legacy, libuarte etc)
and a single 9000 line header file that's used to set global configuration flags for each of them. Most of the examples use the legacy calls, a lot of which then have headers which then forward to the new calls if you've enabled those instead... some work with just the new options set in the header, some work but also need the legacy flags setting, some need the legacy options disabled, the new flags setting *and* some of the legacy configuration set....
I still don't think I understand all the timer configuration flags (timer, app_timer and rtc) and I've read the documentation forwards, backwards and sideways several times.
Firstly the hardware. With the power issues I had with the A9G, fixing those with a hack, then having to add a charging board, then adding a radio board I was looking for something better integrated.
I had hoped that using the RAK5010 would be the answer to my dreams but I still ended up needing some surgery to fine tune it for my requirements.
I'm now eyeing up the Nordic Thingy91 which does look like it resolves these troubles*.... so... perhaps for the *next* incarnation?
*(but undoubtedly there will be other problems instead?)
The long and winding road...
Prototypes 1 and 4 |
It felt silly having a huge case for the tiny processor so I tried a compact variant, it was a nightmare...
The final build of "version 1" ~build #10 getting crowded and messy. |
Two programmers (pictured) needed for this version, one for the nRF bluetooth/ANT firmware and one for the A9G firmware!
I was hunting for a board with GPS, Bluetooth and ANT.... and came across the RAK5010, I thought it looked perfect but in the end I found I still needed to do some heavy duty tweaking.
Hardware
The build, and modifications are shown below.... (yeah sorry, I need to use a decent prototype graphic tool) and obviously, there's a battery too. so imagine a large grey rectangle at the side connected to the red and black wires. 😁 Close ups of all the RAK board modifications can be seen on the earlier post: https://blog.ivor.org/2022/02/between-rak-and-sweet-place.htmlPlease forgive me for this picture. I *promise* I'll get myself sorted with a decent diagramming tool! |
Checking the schematics showed several test pins had useful connections that could be liberated to reuse.
- Firstly, the GPS module needed updating with a more recent firmware to enable hack number 1.
- (but firstly firstly, the tiny resistors needing removing and shorting to connect the GPS to USB)
Removing the *tiny* resistors... - hack 1... the debug pins from the GPS were fed to two IO ports, this enabled a constant ticking data feed.
- the IO ports are only 1.8v... and there's no 3.3v supply so an additional buck converter was added to enable hack number 2
- hack 2... the internal I2C pins were fed through a level converter to enable..
- hack 3... an OLED display was connected to this I2C port
- finally a couple of buttons were added to enable interaction.
Patching in the extra ports |
Sans case, SDCard experimenting... |
Nearly there. The SD Card version build. |
Final build, always looks worse with hot-glue! |
Software
The overview of the software side is below... the software can be found up on github at: https://github.com/ihewitt/raktrack*
also very likely that's *not* the final version yet, I'm still getting the hang of the nRF SDK so I already have a few areas I'd like to rewrite and rework.
*(still needs some cleaning!)
Hopefully lots of useful bits in there, although it would either need reworking if it was to function on a non-modified RAK5010 if desired, also note to use ANT+ devices an ANT enabled softdevice (e.g. S340) needs to be downloaded from the links Nordic provide to the Garmin/ANT firmwares. It's a shame that there's a separate process to get ANT running (you need to agree to a free/non-commercial license and use a "development key" or buy a commercial license) but this could be switched to BLE sensors easily, it's just my sensors are ANT. 😁
In action
(oh I need to get another GlucoRX sensor too, so no blood sugar showing on this one)
Looking good on the tracker.... (once I worked out I'd got day and year reversed and tidied up the glitches.) |
Performance
I remember how hard this all used to be, and try to remember back to some of the projects I've built over the years with veroboard and wires getting components that were "sort of close enough" from Maplin.
Future
Updates!
Had an idea. It now has wireless charging built in! 😄 Can just pop it down on a charger, then pick it up and go.(time, liquid drunk, distance, pace, heart rate and blood sugar) |