.
The SAM-M8Q is ROM based so requires the back up battery (which the modules seem to have) or a way of configuring the ublox on startup eg hacked openlogger or pi unit running serial data.
And thanks David, forewarned is forearmed.
Spent most of the day shopping for a water proof pouch big enough to take the GW52 and logger, but not too big.
Eventually found one in Witworths, an aquapack for an iphone 6, waterproof to 10m. The helmet platform is looking decidedly weird though, Think I'll get a few snide comments at the beach.
Select to expand quotesrtgumbee said..
The SAM-M8Q is ROM based so requires the back up battery (which the modules seem to have) or a way of configuring the ublox on startup eg hacked openlogger or pi unit running serial data.
That pretty much rules out the SAM-M8Q for simple loggers. Memory on the Openlog units is very restricted, so hacking it to configure the ublox units would be tricky. Even if someone did that, updating the firmware to the new version is not as easy as just putting together the logger from parts (once Mike has figured out where to get all the parts).
If GPS size is an issue, look at the ublox 8-based Beitian units. Here's a size comparison:
Beitian BN220 on the left, 280 in the middle, Drotek Neo-M8N on the right. I got good results with the 220, but the 280 has a bigger antenna and gets slightly better reception. IIRC, the 220 was pretty similar to the watch, the 280 better (looking at accuracy values). But the 220 was hooked up to Bluetooth, not Openlog, which can also affect accuracy negatively. I did all the later testing with the chips with the larger antenna.
Select to expand quoteboardsurfr said..
That pretty much rules out the SAM-M8Q for simple loggers. Memory on the Openlog units is very restricted, so hacking it to configure the ublox units would be tricky. Even if someone did that, updating the firmware to the new version is not as easy as just putting together the logger from parts (once Mike has figured out where to get all the parts).
.
I haven't looked at this specifically, but often there is memory available, in the form of Flash memory, even though it sounds like RAM is at a premium. You can store a lot of static information in flash, and with a bit of discipline you can minimise the amount of ram you use. I don't think openlogger would be using much of the Flash at all.
Afterall, the openlog is really just an ATMega the same as the most common Arduino boards.
The other benefit is that you only need to setup the GPS on initialisation and after that you can reuse the RAM for the normal openlogger functions.
One thing that would be good is that a few people have written Arduino code to download compiled sketches from SD card, so potentially it should be possible for the openlogger to boot up, check for a file and then download a new firmware, but you would have to have that feature available in the initial firmware first... which is not impractical.
Select to expand quoteFormulaNova said..boardsurfr said..
That pretty much rules out the SAM-M8Q for simple loggers. Memory on the Openlog units is very restricted, so hacking it to configure the ublox units would be tricky. Even if someone did that, updating the firmware to the new version is not as easy as just putting together the logger from parts (once Mike has figured out where to get all the parts).
.
I haven't looked at this specifically, but often there is memory available, in the form of Flash memory, even though it sounds like RAM is at a premium. You can store a lot of static information in flash, and with a bit of discipline you can minimise the amount of ram you use. I don't think openlogger would be using much of the Flash at all.
Afterall, the openlog is really just an ATMega the same as the most common Arduino boards.
The other benefit is that you only need to setup the GPS on initialisation and after that you can reuse the RAM for the normal openlogger functions.
One thing that would be good is that a few people have written Arduino code to download compiled sketches from SD card, so potentially it should be possible for the openlogger to boot up, check for a file and then download a new firmware, but you would have to have that feature available in the initial firmware first... which is not impractical.
Good point about the Flash memory. But this would still require that whoever wants to build a logger has to first change the Openlogger firmware. From what I've read, that requires at the very least downloading the Arduino IDE, soldering a few extra connections (temporary, for the update only), and then installing the update. Probably trivial for someone who has done this before (although I have read that even experts ran into some issues when trying to get the "black" Openlog units to work by upgrading the firmware). But for anyone not familiar with Arduino programming, it's a major complication. I have done that a bit in the past with the FlySight, and I'd still rather stay away from it. Buying 3 or 4 things, soldering them together, and using them is easy for anyone who can solder. Upgrading Arduino firmware is harder. And right now, there is no firmware version that actually would do what's needed, so it's not an option.
KISS works. It's the reason the first Openlog units are close to (or past?) approval for GPSTC postings.
Select to expand quoteboardsurfr said..FormulaNova said..boardsurfr said..
That pretty much rules out the SAM-M8Q for simple loggers. Memory on the Openlog units is very restricted, so hacking it to configure the ublox units would be tricky. Even if someone did that, updating the firmware to the new version is not as easy as just putting together the logger from parts (once Mike has figured out where to get all the parts).
.
I haven't looked at this specifically, but often there is memory available, in the form of Flash memory, even though it sounds like RAM is at a premium. You can store a lot of static information in flash, and with a bit of discipline you can minimise the amount of ram you use. I don't think openlogger would be using much of the Flash at all.
Afterall, the openlog is really just an ATMega the same as the most common Arduino boards.
The other benefit is that you only need to setup the GPS on initialisation and after that you can reuse the RAM for the normal openlogger functions.
One thing that would be good is that a few people have written Arduino code to download compiled sketches from SD card, so potentially it should be possible for the openlogger to boot up, check for a file and then download a new firmware, but you would have to have that feature available in the initial firmware first... which is not impractical.
Good point about the Flash memory. But this would still require that whoever wants to build a logger has to first change the Openlogger firmware. From what I've read, that requires at the very least downloading the Arduino IDE, soldering a few extra connections (temporary, for the update only), and then installing the update. Probably trivial for someone who has done this before (although I have read that even experts ran into some issues when trying to get the "black" Openlog units to work by upgrading the firmware). But for anyone not familiar with Arduino programming, it's a major complication. I have done that a bit in the past with the FlySight, and I'd still rather stay away from it. Buying 3 or 4 things, soldering them together, and using them is easy for anyone who can solder. Upgrading Arduino firmware is harder. And right now, there is no firmware version that actually would do what's needed, so it's not an option.
KISS works. It's the reason the first Openlog units are close to (or past?) approval for GPSTC postings.
Yes, I agree. Keeping it simple makes it easy. Once you start adding features, where do you stop?
I keep on thinking about features I would want, but then it brings it into a different scope from a simple/reliable data logger.
I hope to find the enthusiasm to return to working on my own version, but until then, I guess, keeping it simple is a good idea.
Thanks for posting pics of Beitian GPS units, I didn't realize the BN220 was so much smaller than the BN280.
I posted the SAM-M8Q as a Genuine Ublox option as this only just appeared on my radar despite looking at GPS options for quite some time.
Some good points made on the lack of backup memory and this is an extra hurdle. Keep in mind the genuine rechargeable backup battery might last a couple of weeks depending on the size of the battery, but this may be a curse if you haven't been out for a while and don't know to trust if the backup battery has gone flat and your PBs results don't end up getting recorded!
With regards to the open logger firmware, I will look into modifying the firmware when my one arrives and report back with the results (good or bad).
Select to expand quoteboardsurfr said..
>>>> KISS works. It's the reason the first Openlog units are close to (or past?) approval for GPSTC postings.
Yep, Andrew has given my unit the kiss of approval. I made my first post with it Monday.
The 220s are hard to come by. I thought I'd found one and ordered it. But the seller said, it would take too long for him to get one, did I mind a 280 instead? So hopefully that's what I'm getting, he hasn't mentioned the extra cost.
Select to expand quotesrtgumbee said..
I posted the SAM-M8Q as a Genuine Ublox option as this only just appeared on my radar despite looking at GPS options for quite some time.
The Beitian units appear to use genuine u-blox 8 chips. The problems with fake units is about NEO-M8 chips. The NEO adds a number of additional things to the GPS chips that can be useful in some situations; one of them is Flash memory. Fake NEO-M8 units don't have Flash, or not enough, or have other cheap components that negatively affect usability or performance. Some have old firmware versions that "dumb down" the chip to u-blox 7 levels (no simultaneous GPS+GLONASS), and cannot be upgraded.
Most of the extra electronics in the NEO-M8 chips (compared to the "bare" M8030-KT ublox GPS engine) are irrelevant for speedsurfing. One big exception is Flash memory to store settings; the Beitian chips have that.
The primary reason to look for genuine NEO-M8 modules like the Drotek was to avoid getting useless or inferior units. If it's a NEO-M8 from a random source, it's a matter of luck how well the unit performs; pictures and descriptions on the selling pages do not really help.
The Beitian chips seems to be branded. They are cheaper than the genuine u-blox chips, which removes the main motive to sell fakes. I have tested three different ones (BN-220, 280, and 800 or 880), and they all performed well (with slightly lower accuracy for the 220 due to the smaller antenna). But while this is better than for fake NEO-M8s, where both Mike and I got bad units, it's still a very small sample. One more reason to require some validation of each individual assembled GPS logger before it can be used to post to GPSTC.
Select to expand quoteboardsurfr said..
................... One more reason to require some validation of each individual assembled GPS logger before it can be used to post to GPSTC.
Which is exactly what we are proposing. Many thanks for your efforts in identifying the fakes and their shortcomings and yours and Mikes efforts to describe the processes, options for building and your trials and tribulations. Draft validation/Approval process is now in consideration and refinement. Hopefully, not far away from publishing.
Gent's,
I've had my share of fake units also, but think about this:
- IF you are already soldering things together how much extra work is it to get a Ublox chip and antenna separate?
Get the best freaking GPS chip and antenna you want and solder it yourself.
- IF you are working with a tiny crazy openlog chip, how much extra work is it to get a decent CPU and program what you want?
There are so much cool low power solutions, with a lot of resources
More than willing to share some design brain farts I've encountered since 2015, everything is already put on paper in the Dutch forum thread!
The hardware is easy, learning to program made it difficult.
I'm busy with the 7th revision of my Gyro unit, REV G, when I started with REV A, it was just a through hole design...
Production in the EU was expensive for me, but Elecrow delivers my custom PCB in 7 days with the $30 delivery option!
Order on Friday before 23.59, delivery on Friday before 21.00, costs around $38,-
www.elecrow.com/pcb-manufacturing.html
Select to expand quoteraymondw said..
- IF you are working with a tiny crazy openlog chip, how much extra work is it to get a decent CPU and program what you want?
There are so much cool low power solutions, with a lot of resources
More than willing to share some design brain farts I've encountered since 2015, everything is already put on paper in the Dutch forum thread!
You're answering your "how much extra work"question there. You've been working on it for three years already.
It took Mike just a couple of weeks to put together a functional Openlog unit that anyone who can solder can reproduce. Anyone whonever soldered before can learn the necessary skills in less than an hour.
I have a variety working GPS units that plug into Android phones via USB; connect via Bluetooth; work with a Raspberry Pi Zero W; and even an older Flysight-based unit with some modified Arduino programming. All of these units have accuracies that are at least comparable to current Locosys units, and often better. They are also all quite irrelevant for different reasons, so I never bothered to seek approval for GPSTC. That's different for the Openlog units.
In all likelihood, most speed surfers will stick to the GW-60, despite whatever shortcomings it has - it works, and it's just too darn convenient. But the Openlog units are a cheap and easy alternative that offers some advantages, like enough battery life for 24-h attempts and higher accuracy. They are simple enough that making some for friends and team members does not take long, once you made your first couple.
That is what I mean to say...
I f someone can build a simple unit in a couple of weeks, why not take all the knowledge and create something that is even better.
This was my first 10hz unit, just 4 weeks after I started, most of the time spent learning how to solder, learning electronic rules and how to program the Arduino.
forum.windsurfing.nl/viewtopic.php?f=62&t=13890429&start=30#p7354903
The reason I'm working for 3 years on my units is the GW-60, everybody can buy the watch.
So my project will just be project stage and I will work on it when I'm not windsurfing, flying the drones, simracing or working...
And sometimes I sell units to make people happy
For the "download a log file via USB" part, USB works best via operating system like Freertos.
It is difficult (almost impossible) to create something as a MSC/MTP device on an Arduino programmed unit.
Select to expand quoteraymondw said..
For the "download a log file via USB" part, USB works best via operating system like Freertos.
It is difficult (almost impossible) to create something as a MSC/MTP device on an Arduino programmed unit.
Yes, its surprisingly difficult. The Teensy boards had some provisional support I think, but it looks like it was never finished.
I have thought that if you need USB download it would probably be as easy to have a virtual serial port and transfer it using something like ZModem. Probably not as fast, but still plenty fast with the right Teensy board.
Select to expand quotesailquik said..
And it appears even easier to build a simple BT GPS and log to an Android phone. 
Shhhh...don't tell everybody Andrew or they'll all be doing it!
Select to expand quotesailquik said..
And it appears even easier to build a simple BT GPS and log to an Android phone.
Incorrect and misleading.
Building a BT GPS does require exactly the same effort as building an Openlog GPS: soldering 4 wires, and hooking up a battery.
Configuring the Openlog unit requires editing a text file. Configuring the BT unit requires a serial connection and issuing an AT command over it. That's marginally harder. Both setups require configuring the GPS chip.
Getting the actual GPS data from the Openlog units requires plugging in a micro SD card into a computer, and copying the file. Very similar to a GT-31, and easier than getting data of a newer Locosys unit.
Getting the Android phone to actually log the required .ubx file requires Android programming, since the Bluetooth version of GPSLogit that sailquik has been using is not publicly available. That is substantially harder than soldering a few connections (perhaps unless you happen to develop Bluetooth programs for Android for a living).
If you happen to get past these little hurdles (I have), then you end up with a device where the Bluetooth module puts out an RF frequency signal that is a quadrillion times more intense than the GPS signal that the antenna is trying to pick up (see boardsurfr.blogspot.com/2018/06/1000-million-millions.html). The BT frequency is about 50% higher - not close, but not extremely far away, either. Therefore, using Bluetooth leads to RF noise in the GPS signal, and lower quality data. Example data are at boardsurfr.blogspot.com/2018/06/interference-and-data-overload.html
The Openlog GPS units are the easiest custom GPS units to make for applications like speedsurfing where we want accuracy data, and there are strong indications that they provide better accuracy than currently approved commercial units and Bluetooth units.
Select to expand quoteraymondw said..
If someone can build a simple unit in a couple of weeks, why not take all the knowledge and create something that is even better.
What are "the" criteria for better? There have been plenty of discussions that showed everyone has different criteria.
If convenience with some feedback is most important, the GW-60 is very hard to beat.
If instant feedback while sailing and/or more detailed feedback in breaks and after the session is most important, then Android apps like Windsport Tracker and GPSLogit win.
But if price, accuracy, long battery life, simplicity, and "easy to make your own" matter most, then the Openlog-based unit Mike has described rules. As soon as you try to create something "even better", you'll take an immediate hit on most or all of these criteria.
"Mike's DIY GPS Logger" won't replace the GW-60, and won't even be an alternative to it for anyone who wants to see speeds on the water. But there are a few scenarios where it makes perfect sense:
1. As a backup GPS (for those who usually use 2 GPS to be safe, or for the times where wrist bands breaks, ...).
2. Together with a phone and Windsport Tracker/GPSLogit for instant feedback and accurate data.
3. For anyone who just wants to record a session, and look at the data later at home.
4. For anyone who wants a GPSTC approvable GPS, but cannot or does not want to spend the money on a GW-60.
5. For long distance attempts or multi-day trips without having to worry about recharging after every session.
Just about 100% there Peter.
I normally sail with the GW60 on my wrist for on the water feedback, and the GW52 on my head for accurate posting.
I've had one GW52 die because I used wet hands opening the waterproof pouch. Next session I had condensation inside, shortly after the GW52 USB connection started to play up, then stopped working.
The GW52 battery life is just about long enough for me to do a distance, but data storage isn't.
My solution has been to use the old GT31 on my head for distance days, it's 10 years old now, maybe just a tad past it's prime?
Then there's the problems with GW60s, mine has shown signs of condensation on the glass on cold days, the "GPS" button is getting a bit touchy. it's coming up for 2 years old now, so from other people's experience it may not function much longer?
So a reliable accurate logger with good battery and storage life made very good sense.
I felt making one was within my capabilities, although at several times through the process I had serious doubts!
Anything more complex, would certainly be pushing the boundaries, and at the moment there's no incentive to take on a bigger challenge.
I'm in play mode now, once the battery management stuff and bietien 280 arrives, I'll try and make a smaller unit, and experiment with higher acquisition rates.
Select to expand quotesailquik said..
And it appears even easier to build a simple BT GPS and log to an Android phone.
Isn't there a problem at the moment where the author of that software is no longer making it available? I think you would find it would be easier to take up that option if it was actually available 
Me, I can see both cases, I think it would be good to have the data logged at the GPS and also sent to the phone for display information and possibly a backup.... but without the software I can't even test the bluetooth capabilities.
Select to expand quoteFormulaNova said..sailquik said..
And it appears even easier to build a simple BT GPS and log to an Android phone.
Isn't there a problem at the moment where the author of that software is no longer making it available? I think you would find it would be easier to take up that option if it was actually available
Me, I can see both cases, I think it would be good to have the data logged at the GPS and also sent to the phone for display information and possibly a backup.... but without the software I can't even test the bluetooth capabilities.
Its a bit of a egg and chicken thing.,,,,,,
i think it might be available if people ask for it nicely.
Select to expand quotesailquik said..FormulaNova said..sailquik said..
And it appears even easier to build a simple BT GPS and log to an Android phone.
Isn't there a problem at the moment where the author of that software is no longer making it available? I think you would find it would be easier to take up that option if it was actually available
Me, I can see both cases, I think it would be good to have the data logged at the GPS and also sent to the phone for display information and possibly a backup.... but without the software I can't even test the bluetooth capabilities.
Its a bit of a egg and chicken thing.,,,,,,
i think it might be available if people ask for it nicely.
I don't know Manfred (it's Manfred right?), so I don't even know how to ask for it. Last I read here it was no longer available on the play store because of changes in privacy requirements.
I think that sort of setup makes more sense. Updating software on a phone, and being able to use almost any phone makes a lot of sense. A cheap phone has a far better display than you can build yourself for the same price.
If/when the GW60 dies, it will be a hard call, - by another one, or go back to a cheap phone on my arm.
I've got used to the watch on my wrist, a pouch on my arm is a pain.
Battery management modules just arrived in the post, so I've got something to play with again.
Select to expand quoteboardsurfr said..
... you end up with a device where the Bluetooth module puts out an RF frequency signal that is a quadrillion times more intense than the GPS signal that the antenna is trying to pick up (see boardsurfr.blogspot.com/2018/06/1000-million-millions.html). The BT frequency is about 50% higher - not close, but not extremely far away, either. Therefore, using Bluetooth leads to RF noise in the GPS signal, and lower quality data. Example data are at boardsurfr.blogspot.com/2018/06/interference-and-data-overload.html
The Openlog GPS units are the easiest custom GPS units to make for applications like speedsurfing where we want accuracy data, and there are strong indications that they provide better accuracy than currently approved commercial units and Bluetooth units.
Your blog doesn't indicate which version of Bluetooth you are using - BT version 4 uses spreadspectrum so shouldn't really interfere.
Was the test using BT v1 or v2 ?
Select to expand quotemathew said..
Your blog doesn't indicate which version of Bluetooth you are using - BT version 4 uses spreadspectrum so shouldn't really interfere.
Was the test using BT v1 or v2 ?
Spread spectrum was introduced in Bluetooth 1.2, so I'm not sure why you think that BT 4 would be any better. The energy consumption specs for BT 4 serial transceivers are similar to the HC-06 that I used.
You could make the theoretical argument that Bluetooth should not interfere with GNSS since the frequencies are quite different - around 2.4 GHz vs. 1.6 GHz). Actual observation shows that you're about 99.999999999999% correct. Unfortunately, since the GPS signal is about 1000000000000000 times weaker than the signal emitted by BT transceivers, that's not good enough to eliminate all interference.
Maybe a BT 4 transceiver could have less RF interference simply because you can reduce the power output of the signal easily. Maybe you'd also get good enough communication between the module and the phone to record sessions reliably even at low-power modes. But you'd always need to use two separate devices, the phone and the GPS. Your recording will fail when one of the two devices has a problem - for example, when the phone battery dies.
If you don't mind strapping on two additional devices, you may as well leave the phone and the logger completely independent. Use the phone GPS for feedback during the session, and the logger for high-accuracy recording. The logger will keep recording long after the phone battery dies. It will work perfectly fine without of any bluetooth connection issues, or when you don't want to carry a phone.
The only advantage of using a ublox-bluetooth-phone combo is that you may get higher accuracy feedback than from the phone's GPS. That applies only when you are using the speed announcements, or look at the phone screen in a middle of a speed run. But the vast majority of the time, any differences will be too small to notice, so there really won't be any advantage.
That's at least the conclusion I have come to after building quite a few GPS prototypes, including on that can use both Bluetooth and Openlog. But by any means, build your own Bluetooth 4 prototypes, "ask Manfred nicely" and hope you get some software to make it work (or write your own), and let us know how it goes.
Select to expand quoteboardsurfr said..
If you don't mind strapping on two additional devices, you may as well leave the phone and the logger completely independent. Use the phone GPS for feedback during the session, and the logger for high-accuracy recording. The logger will keep recording long after the phone battery dies. It will work perfectly fine without of any bluetooth connection issues, or when you don't want to carry a phone.
.
Thinking about that now, that makes perfect sense. Why use BT when the phone's onboard GPS is enough for the phone to give meaningful feedback, and the accuracy data doesn't need to leave the GPS.
I was thinking that you could embed other information into the stream from the GPS to the phone, but there is nothing that's really critical that can't be done on a simple display on the GPS.
