Close

Streaming heartbeats

A project log for Heartbeat Logger

A portable device that logs a snippet of your heart at the push of a button.

Ole Andreas UtstumoOle Andreas Utstumo 10/28/2016 at 13:576 Comments

Giffed above is the Logger streaming data to my Surface via the HC-06 bluetooth module. All the bytes are sent to the virtual COM port and displayed using a processing sketch. It works out really well, in fact. The only issue is that there are no synchronization bytes, and since each sampled value is packaged into two bytes, there's a 50/50 chance of the sketch grabbing the correct byte first when you start it.

Discussions

helge wrote 11/29/2016 at 18:32 point

Oh, look at how stick-to-it-ness pays off. This looks really great! Now as for that data transmission issue from first hand experience I'd say it's much more hassle to resynchronize to a bitstream with a heuristic algorithm than to use frame based transmission. The latter also allows for meta data to be attached to the stream. decoding the data becomes a matter of bufferering 2-3 frames worth of data and aligning the readout cursor such that a succession of valid frames is observed. Validation can be done by range checks and checksum matching. Once locked onto, no additional buffering of the stream beyond one full frame is required.

  Are you sure? yes | no

Ole Andreas Utstumo wrote 12/06/2016 at 09:32 point

Thanks for the tip, helge! I did consider doing a range check on the current heuristic algorithm as a quick fix, but getting a grasp on a proper way of transmitting data does hold a value. I'll look into it :)

  Are you sure? yes | no

helge wrote 12/06/2016 at 20:12 point

having fixed header and data sizes helps a lot. The major annoyance with the protocol I came up with is you need to know all frame structures (checksum position and data length position) to be able to decode a stream. If you need to implement variable length frames, put the data length and checksums in the header at fixed offsets. Lesson learnt ;-)

  Are you sure? yes | no

Ole Andreas Utstumo wrote 12/07/2016 at 14:03 point

Yup, that makes plenty of sense! I'm guessing you're using a checksum algorithm based on CRC?

  Are you sure? yes | no

helge wrote 12/07/2016 at 15:04 point

using a high level connection like SPP over bluetooth guarantees that you'll either have no data at all or consistent data. With that in mind, XOR checksums are mostly ok. With a little bit more effort CRC8 or CRC16 can be generated (basics, see Microchip AN730, code example http://www.avrfreaks.net/forum/crc-8-bit ) - might be worthwhile. XOR checksums make me nervous when they come out to have values already present in the frame or are just zero.

The most low power implementation would be to use a LUT for CRC8:

http://www.barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code

  Are you sure? yes | no

Ole Andreas Utstumo wrote 12/07/2016 at 20:15 point

I appreciate it, helge! Thanks! I'll be sure to write an entry about the data transmission when I implement it :)

  Are you sure? yes | no