dsco

Here's a GitHub link: https://github.com/LoonSongSoftware/B-G-H5000-Logger I used it today to log several hours' sailing. (Compiled on a Raspberry Pi, as I think I indicated above.) There's still more cleanup and documenting to do, but I have lots of competing priorities, so I thought I'd put it up on GitHub and continue to work on it/respond to questions or comments over time.

Intro Owners of B&G H5000-based systems may have noted that B&G includes information about how to configure and control the system via a "websocket" interface. One of my projects has been to capture the H5000 CPU websocket data (which is sometimes different from what's available on the NMEA0183 and N2K interfaces) via a really simple application that can be run on a Raspberry Pi. (Instead of running, for example, Expedition on a laptop to capture the data--no sense running a fully powered-up laptop when something with much lower electrical draw will suit.) The Question Anyway, here's my question (hoping that someone from B&G monitors this forum): The "UTC Date" data item (ID 34) comes in this format: 34,1,2.45909e+06,2.45909e+06,2.45909e+06,0,0 (where the fields are: id, valid, value, system_value, damped_value, instance, damped) For the life of me, I can't figure out how to translate 2459090 to a sensible date (this number represents October 9, 2020). It looks like the number increases by 1 per day (so 2459092 would be October 11). Most computer integer representations of dates are based on "number of days since..." where the "since" refers to 1/1/1901, 1/1/1970, or similar. But this number goes back to something like 4500 BCE. I can certainly hack the calculation, but I'd be interested in a more elegant way, if it exists. Anyone know what the format is? If You're Interested By the way, if anyone's interested in logging this data on a Pi (or any other computer), let me know and I'll put it up on GitHub. I build and run it in Linux for the Raspberry Pi, but I develop it on a Windows machine, so I think (maybe with some modest changes) it can run on any Windows or Linux machine. I use it both for calibrating my instruments and maintaining a "VDR-type" log of all of my sailing--it's useful for analyzing performance after the fact.

Thanks. I hadn't seen that code. But I was looking for something more direct and "lightweight" than running C# via Mono on a Linux machine. (The sample code in the B&G documents is also C#/.NET code.) I was looking for something straightforward to compile and run on a Raspberry Pi as a command line application. As requested, I'll post the code shortly (maybe tomorrow). I'm doing a bit of cleanup and writing some build instructions.

Will do. I'll do a bit of code clean-up and add some build instructions to the README.md.

Thank you! That looks exactly right. Now I'll look more closely at what might have caused the 2460000 glitch. I remember the switch from Julian to Gregorian, but that's about it. Had no idea that the Julian day-count started at 4700 BCE. Now I know. Thanks again!

By the way, it seems even more confusing. August 19, 2020 seems to be 2460000, which is higher than even October 9, 2020 (2459130). With August 28 (2459090) in between...