I'm trying something a bit different, still 2 boards, but they look quite small.
www.aliexpress.com/item/32790658678.html?spm=2114.12010108.1000023.9.35d7613fbLiEto
This is a charger and booster combined.
And this is the protection board.
www.aliexpress.com/store/product/3-7V-4-2V-3A-Li-ion-Lithium-Battery-Charger-Over-Charge-Discharge-Overcurrent-Protection-Board/1525466_32803131082.html?spm=2114.12010612.0.0.mlFzON
I've never dealt with aliexpress before, so it will be interesting to see what I eventually get and how it works.
Can an existing GPS be hacked to make it better rather than starting from scratch. Make a good one great by tweaking some part of it or stealing from others. Like Canmore with a large readable screen. An older GT-XX with bigger card or the watch that doesn't break.
When the diy ones are sorted I'll be forking out to get one, over the production GPS units that have short comings.
GREAT work to all involved
Unless you're a top gun hacker, improving an existing unit would be extremely hard if not impossible.
I don't think anybody is going in to production, but I don't mind helping a bit with the build, as you say once we get it sorted.
Select to expand quotedecrepit said..
Charges up the power bank, and you guessed, it wouldn't stay on. But I figured the 180? resister would be very close to keeping it on, so I kept switching it back on. After about 20 tries it stayed on, so I'm leaving it on for an hour or so, so it should work tomorrow.
Bought a 14500 800mAh tagged lithium battery. The 18650, at 18mm dia is too big, the powerbank is 15mm thick which is very tight.
The booster they had was also too big, so I'll have a look on line.
Are you talking about the 'Arduino' 5v booster Jaycar sell? I bought one of those too, but I never got around to using it. I think these are bigger because they have a USB connector for the 5v output. The modules that you have now bought will work out fine, as they are generally quite low profile.
Select to expand quotedecrepit said..
Unless you're a top gun hacker, improving an existing unit would be extremely hard if not impossible.
I don't think anybody is going in to production, but I don't mind helping a bit with the build, as you say once we get it sorted.
It would be more work than starting from scratch I think. The ublox GPS modules are well known, and there seems to be enough info on RaspberryPi and Arduino to make a new custom project way more effort.
The parsing of the GPS information seems to be covered quite well, and even though you are not using this real-time information, its pretty trivial.
My ambition is to use 1 or two OLED displays. They are tiny displays, but are very bright and cheap. One is enough to show 3 digits in a large font suitable for looking at while sailing, and due to their high resolution you can also show a decent amount of text on them, albeit in a font too small to use while sailing.
Look forward to seeing your display results Formula, it's obviously a big advantage for people who only want one device.
I had another session yesterday, so I've been doing more number crunching for approval.
I got the last one a bit wrong, summing the +/- numbers isn't correct, we need to see that there is an overlap between possible speeds.
Yesterday I was wearing a loose spray jacket, so the logger slipped around a bit on my arm, possibly why there isn't the same runs in the top 25.
So they all overlap, although I had to check the 13:44:54 run to make sure.
You can see above why I do a time sort first, (the 18s difference doesn't help) but it makes sure the same runs are compared. If it's left in a speed format, you can easily be comparing different runs.
Select to expand quotedecrepit said..
I got the last one a bit wrong, summing the +/- numbers isn't correct, we need to see that there is an overlap between possible speeds.
To see an overlap between the possible speeds, you look at the ranges. The lower number is average + error, the higher average - error. Comparing the difference between averages to the sum of the error estimates is exactly the same. If the difference is lower than the sum of errors, the ranges overlap.
I just got some extra motivation to get my units approved in yesterday's session. It was windy all day, and my GW-60 battery died after 5 1/2 hours, despite being fully charged (and it sure was warm!). I probably used the watch for ~200 sessions, so the battery life is going down already. Many lithium batteries get just a couple of hundred charge cycles before capacity drops noticeably.
Can you perhaps expand on how exactly I can get units approved? I understand the comparisons to the GW-60 or 52, but who exactly do I contact to get the "official" ok?
Thanks Peter, I checked again and found I was right the first time, don't know what I did the second time, to get a different result.
Anyway, Daffy is the man to talk to.
Because of the missing result at 13:31 and out of interest, I've added the GW60 to the 10s comparrisons.
That also has 13:31:34 missing. Looking at the speed graph, they all have about the same Max speed at that point, but the GW52, has it for longer. And strangely the watch has the best SDoP and the GW52 the worst?
GW52 on Left, (on head). GW60 in middle, (on wrist of course). and logger at right (on upper right arm)
Not quite what you'd expect. And isn't reflected in the other results.
I hadn't bothered including the watch in these comparisons, as I thought the watch on my head was always going to be more accurate. Looks like that isn't always the case. So future comparisons will be a 3 way affair.
And I'll arrange the table with the logger in the middle so I can use 2 difference columns
Select to expand quotedecrepit said..
Because of the missing result at 13:31 and out of interest, I've added the GW60 to the 10s comparrisons.
Mike, the problem here is that the 29.5 knot run at 13:59 is missing from the GW52. I bet that you'll see a missing data point there in the GW52 data. It's also possible, but less likely, that one point there has a high acceleration or SDoP that triggers the filters. GPSResults will not include a region if a point is missing or filtered out.
Since this region is not used in the GW52 data, the 20th-fastest 10 second run is the one at 13:31with 21.2 knots. In the GW60 and logger data, the 20th-fastest run is 22.9 knots at 15:55.
I have seen similar examples several times; if there was a disagreement, the problem usually was in the Locosys data. Although on the other hand, one could certainly argue that the analysis software should not discard an entire region because a single data point is missing when were are dealing with 5 Hz+ data. Even with a missing data point, data points are still at most 0.4 seconds apart, and should be more accurate than 1 Hz data from GT-31s that are still allowed.
Hmmm, I didn't check the GW52 data at 13:49, I was more concerned with the logger missing the 10s at 13:31.
I'll go and check the GW52 now. Back soon.
Yep, spot on Peter.
GPSResults filters ignore intervals with missing points. unticking filters brings it back in, but the GW52 has gone down to 4 sats So the missing data points are probably due to loss of sats, why that should happen to the unit on my head but not the ones on arm and wrist is a puzzle?
I think I have a theory, I run the paqua armband over the top of the pouch on my helmet. I position the GW52 so the antenna isn't under the armband, but if it moves around, I'm fairly sure a wet salty band would kill the sat signal.
There's a 36s gap in the GW52 data, just before it starts coming back with 4 sats. It looks like it started while I'm walking upwind, was I resting the sail on my head?
Anyway, I'm trying to work out a way of mounting without the armband on top.
Interesting that a wet armband on top of the GPS might kill the signal so much. You are quite good at finding things that can go wrong!
On occasion, I have observed similar problems with Locosys units worn on my arm or wrist, without any apparent reason (like crashes, swims, etc.). There'd be multi-second gaps in the middle of the run, followed by shorter stretches with a marginal number of satellites. The only times I noticed this was when I was comparing GPS units, or when I also used GPSLogit and the GPS display would not show the speeds I heard, so I'd look closely. Not sure this is what's going on in your case, just thought I'd mention it.
Yes the worry is, if I'd only had the GW52 on my head, I would have assumed the missing data was from a crash, where I'd gone under water, because I have stopped there.
I'll do some tests and see just how much a salty wet armband over the antenna affects the signal.
I've just started to make a cap for my helmet, that hopefully will hold both units. Still very much in the development phase at the moment. If I can get it to work I'll post some pics.
Haven't done any wet armband tests yet, but ot be on the safe side. I packed the GW52 into the paqua midi so it couldn't move, and the antenna stayed well clear of the armband. I have it doubled over the paqua, and it's a soft absorbent material, so I wouldn't be surprised if it totally kills the sat signal once full of saltwater.
It was only a short session yesterday, too choppy and not much fun, but I did get some interesting results.
Lots of gaps in the spread sheet, all at low speed. I'm not really sure what's causing this. The speed graphs look very similar, I see no reason for the difference, unless it's got something to do with the, "one per run" rule. Because to me they seem to be on the same run, speed doesn't drop to 0 and there's no gybe, so maybe, if speed drops below 5kts, that triggers a new run?
More investigation needed.
However, all the results are again very close, and no strange loss of signal with the GW52
More data today.
A bit choppy for me when the wind blew, and not enough wind when the water smoothed out a bit. So although no fantastic speeds, I did manage some 10s runs faster than 5kts.
So no gaps, and all the accuracy envelopes overlap. The watch has the biggest differences, but that's to be expected with the underhand grip, and smaller antenna.
The differences are significantly better after 14:15. It was mainly stormy today, but with some small sunny periods, so could this be weather related? It doesn't seem to be reflected in the accuracy data.
Select to expand quotedecrepit said..
More data today. ... So no gaps, and all the accuracy envelopes overlap.
I suggest that you ignore the low speed data. The Locosys units have a low-speed filter that tends to keep the speed at or very close to zero. This means they have better accuracy when the speed actually is zero, but they often show a pronounced lag when you start going. Here's an example (ublox blue, GW-60 red):
A more dramatic example from a rotary test, where I started and stopped the (slow) rotation several times:
Speeds were around 1-2 knots. The Locosys unit (read) did not pick up the speed at all. But you can see at the beginning that it stayed closer to zero when stationary, too.
For speedsurfing, these things don't matter. The primary categories time where low speeds may count at all are one hour and distance, and low speed contributions will be very small. GPSResults likes to filter speeds below 5 knots completely. Theoretically, this could also affect alphas if you loose all speed in the middle, but these alphas will be poor, anyway.
For testing, use a smaller number of top speeds if you have a short session.
Select to expand quoteboardsurfr said. >>>>. GPSResults likes to filter speeds below 5 knots completely. Theoretically, this could also affect alphas if you loose all speed in the middle, but these alphas will be poor, anyway.
For testing, use a smaller number of top speeds if you have a short session.
First think I do when I open a file in GPSResults, is set min speed to 0. I wish I could find a way to make this the default.
I wasn't putting any importance on the low speed stuff, I was just interested by the differences.
I have been following this thread with intense interest.
Mike has done a great job of construction and testing.
Peter has contributed invaluable knowledge, research and testing.
Well done to both of you.
It is obviously time to publish a formal Validation/Approval process for the use of these DIY ublox M8 based GPS devices on GPS Team Challenge for those who wish to do so.
Mike has fullfilled the process we have in mind in this thread for all to see
Stay tuned (while we dot the i's and cross the t's), for an announcement and documetation very soon.
Thanks Andrew!
It's been an interesting and informative journey, if a bit frustrating at times.
But ending up with a logger, with a more accurate and longer recording time is very satisfying.
Great effort Mike!
I got stuck with a cheap Chinese Ublox with old firmware I could not upgrade. I have no GW52 (or similar) to compare it to.
Having a UBLOX approved will prove any genuine UBLOX (eg Drotek) is good enough for what we need and that even some Chinese UBLOX units are good enough to get approved 
Just a point regarding adding DCDC power supplies to the units is these DCDC supplies will introduce noise to the system and that MAY (or MAY NOT) effect the performance of the Ublox module. It would make sense that if one is using a DCDC power supply module then it should be used when producing results for the approval process.
Select to expand quotesrtgumbee said..
Great effort Mike!
I got stuck with a cheap Chinese Ublox with old firmware I could not upgrade. I have no GW52 (or similar) to compare it to.
Having a UBLOX approved will prove any genuine UBLOX (eg Drotek) is good enough for what we need and that even some Chinese UBLOX units are good enough to get approved
Just a point regarding adding DCDC power supplies to the units is these DCDC supplies will introduce noise to the system and that MAY (or MAY NOT) effect the performance of the Ublox module. It would make sense that if one is using a DCDC power supply module then it should be used when producing results for the approval process.
The validation process we have in mind (and in draft) will require each individual build to be checked against a GW-52 (preferably) or a GW-60 at 5hz. It should not be hard to borrow one for a few sessions should it? We may be able to accept results comparison with a GT-31 by negotiation.
This is just to make sure the build is working as it should. We already know the ublox GPS is fine if assembled correctly with the other parts.
An alternative that could be considered if someone does not have a GW52/60 would be to accept data from two separate ublox 8 units, perhaps together with GT31 data if someone only has a GT31. If there are any issues with the build or the chips used, they should show up as differences. Furthermore, problem units would be likely to have high sAcc values. Cost per unit could be around $40-$50, so building 2 is still quite reasonable.
Select to expand quoteboardsurfr said..
An alternative that could be considered if someone does not have a GW52/60 would be to accept data from two separate ublox 8 units, perhaps together with GT31 data if someone only has a GT31. If there are any issues with the build or the chips used, they should show up as differences. Furthermore, problem units would be likely to have high sAcc values. Cost per unit could be around $40-$50, so building 2 is still quite reasonable.
That sounds good too.
Select to expand quotesrtgumbee said..
Great effort Mike!
I got stuck with a cheap Chinese Ublox with old firmware I could not upgrade. I have no GW52 (or similar) to compare it to.
Having a UBLOX approved will prove any genuine UBLOX (eg Drotek) is good enough for what we need and that even some Chinese UBLOX units are good enough to get approved
Just a point regarding adding DCDC power supplies to the units is these DCDC supplies will introduce noise to the system and that MAY (or MAY NOT) effect the performance of the Ublox module. It would make sense that if one is using a DCDC power supply module then it should be used when producing results for the approval process.
I know of one person locally who has a GW-60, I will ask him first. Failing that I know I can it send it away to someone who can help me.
My assumption is a cheap Chinese Ublox with 2.01 ROM firmware (no GPS+GLONASS) that I have does not provide accuracy that is required for our needs, based on that assumption, I didn't want to hassle other people to help with the GW-60 testing as it was likely to be a fail.
I was excited to hear Mikes Ublox (3.01 firmware?) works well and I could buy one of those modules (or a Drotek) to almost guarantee it will pass the testing required 
.
Select to expand quotesrtgumbee said..
>>>> >>> (or a Drotek) to almost guarantee it will pass the testing required .
Careful the jury is still out on the Drotek. Boardsurfr, says it seems to add the NMEA sentences back in after they've been programed out.
The main problem, apart fro, extra file sizes, is the possibility of overwhelming the system with data, causing lost points.
I have a Beitian 280 on order, it's a smaller cheaper unit. It probably won't be as accurate as the Neo M8N, but I hope it's as good as the GW52 and better than the watch.
The unit I've just made is just a bit too bulky, so I want to explore ways of decreasing size.
I managed a few half decent alphas Monday, wind was light when water flat, and choppy when wind picked up, so nothing great.
But it did throw up a difference between the logger and GW52 that has no overlap in the accuracy envelopes. A 0.111kt difference but only a 0.93kt combined envelope. Both alpha results look very good, I can't pick a problem with either of them.
So again, I've referred to the watch. This is only different to the logger by 0.01kt and different to the GW52 by 0.121.
With GW52 on head, logger on right arm and watch on right wrist, this could be a genuine difference between head and arm movements in the gybe.
The dual head mount is coming on, I'll get a better understanding once both antennas are side by side on my head.
The first result is the worry, all the rest are fairly close. the difference could be the way I sometimes throw the sail over in the gybe.
The difference is about 0.1 knots, which is still pretty good. I'd expect the accuracy of the GT-31 in alphas to be a lot worse due to the heavy filtering in the device.
The "error envelops must overlap" approach is great for 2 and 10 seconds, but it has its limitations when you go to longer times. If you look at nautical miles or 1 hour results, you will find that the ranges often do not overlap. That just shows that errors are not completely independent over longer time periods, so that the assumption that errors average out is not completely valid anymore. The alpha in question is a 45 second long run; longer periods give you a higher chance of picking up regions where the error is biased. That bias would have to be only +0.02 knots in the GW-52 data to get the non-overlap.
You may be measuring a real speed difference. With the GW-52 was on the top of your head and the watch and logger were on the inside arm in a jibe, the radius and therefore speed would be marginally slower . If that theory is correct, then your watch arm would have been outside on the second alpha, and inside on #1, 3, and 4. Would match the times if your runs were about 1.5-2 km long...
