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

Firstly a quick mention for the "why" which has been asked several times along with "but I can do X" on my phone... this is to monitor health during long endurance events *for the benefit of the crew* so they can see what's going on and spot any developing issues. 

A phone *can* do some of this stuff, but doing it all at the same time is not simple. If I'm in an event, I want to carry a cheap phone *that will always work and have charge* if I need it and not worry about it. Yes phones are getting cheaper and battery life's longer, but it's still useful to have a separate device.

Secondary is because it's a fun project and interesting to work on. 😀 - e.g. I've just completed someone else's project to make a VO2 max meter - I don't *need* one.. but....fun.

Finally, it's all under my control using my software, I know it will (or won't) work, if I want to change something or add something I can.

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...

Right from the start - I *think* I'm up to rebuild 11 now....

Getting started with a LinkIt one... and figuring out what the display should show before moving over to the A9G.

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...

#6 and the aborted attempt 7

but #7 was always flaky

Besides the large case made it easy to work on and when I decided to add a bluetooth board there was plenty of room.

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.html

Please 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.

Note: there's currently a bug in this build where the board doesn't start up until the small GSM power button is pushed, this shouldn't happen, and I'm trying to ask and figure out what I've got wrong. It's bound to be something stupid and obvious. Still it's not the end of the world.

Note2: Figured out a fix/workaround for the power issue... enabling the VDD line by adding the missing resistor R76 and the behaviour is now as expected! Similarly, checking the schematic, I really can't understand how or why it would have powered up properly without this before.

Patching in the extra ports

Initially I added on an SD card reader but then found it was really easy to make the board behave as a USB memory stick when connected to a PC so removed that for simplicity so now I've still got two ports free in case I think of anything else.

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. 😁

The build uses lots of the features of the nRF52, I'm particularly pleased with how simple this has ended up and how well it works. A little more intelligence is needed in the USB connect/disconnect logic, but that's only required occasionally so not a big issue.

Obviously while running the data is uploaded to the web service, but it also gets recorded onto the device memory. This can then be accessed simply by connecting the board to a computer where it pops up as a USB drive, very neat. 

In action

Up and *running* (groan) still some tiny glitches - I was clearing the sensor data between samples - and I *think* I know what's causing those double uploads... but other than that, running beautifully.
(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.)

I suppose I need to get a long race booked now, the initial trials *have* been bug-fests, but the output is now looking really good... the battery life looks even better. I haven't got definite figures but it seems to be good for several days, I'll do a run-down test to see.

The GPS lock is considerably better than the A9G, albeit with a more annoying interface and the mobile connection is much more stable.

Performance

Just a last note to applaud the performance of this hardware too, in just a handful of years the quality and performance of GPS chips has improved considerably, this gets a solid lock in a few seconds outside..... I can get a lock **indoors** while I'm testing!

The power usage of the nRF chipset is stunning, and it does bluetooth and ANT radio without skipping a beat, and to be able to buy this sort of device all together and ready for prototyping on a RAK5010 board for £50 is still something I'm totally amazed by. We are living in the future.
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

I'll see how this goes for a while, but already it's tempting to wonder if it's worth getting a custom board fabricated for projects like this, that might be a fun exercise, or if there's an off the shelf component already, e.g. the Nordic Thingy:91 does look like a good package, but also.... who knows maybe RAK will pop-up with something new too.

Of course, it will be good to actually complete a decent endurance event and see if this helps, but at the moment I'm sort of "resting" from that for a little pause.

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.

and it broadcasts its state on BLE so now a watch can be used as a HUD:

(time, liquid drunk, distance, pace, heart rate and blood sugar)

Latest run (95miles) showing full telemetry with glucose warnings: