Select to expand quoterp6conrad said..
The mounting on the boom has the disadvantage of also measuring the "chop". Here you see a speed graph of 2 loggers mounted on each side of the boom (analysis from sailquik). You see a nice correlated "sawtooth", which indicates that these are micro speed "changes". I would suspect that a GPS-watch should have the same issue, as the hands are attached to the boom. But the watches are not logging@10 Hz, I believe the best is the GW60 @ 5Hz. I plan to a test with 4 loggers, 2 on the boom and 2 on my helmet to have more data about this issue.
The other disadvantage is a complett loss of signal when the logger is submersed after a fall. Sometimes, you get weird spikes when the gps signal is very weak. I build in a filter (min sats, min sAcc) for the readings, but this need still some tweaking. In the logs, nothing is filtered, but that is taking care off when results are calculated in GP3S.
But for "recreationial" speeding, the boom position is my favorite !!
Yes, unfortunately, any 10Hz and above device, especially, boom, mast or board mounting is going to measure severe micro accelerations/decelerations over chop. The wrist mounted 5Hz GW-60 also does this to some lesser extent in some conditions, which is one of it's disadvantages.
Just using the extension strap and mounting the GW-60 on your upper arm/bicep, does give notably cleaner results. Likewise for those who now mount their band-less GW-60's in and arm bag. 
If you aim is purely for on the water instant feedback, try mounting the device on your forearm. There are two advantages of this. The first is that it is much more visible as you sail, especially when it is on your front arm, and secondly, it tends to stay in the top of your arm regardless of underhand or over hand grip. I used to use my Foretrex201 in a small armband on my forearm, for this reason, all the time in the very early days. 
Alternatively, and this is my favourite way. Use a cheap Android smartphone on a good arm bag, like the older H2Oaudio bag, with the GPS-Logit app running with the speed talk activated. Most of the time I can hear the speed talk just fine without needing earphones, especially if your phone has a nice loud internal speaker. 
GPS-Logit gives me full screen feedback on all the GPSTC categories as well. Using the internal GPS it is ballpark close enough for good feedback. Using a Bluetooth connected Ublox GPS device (mine is Ublox M8 @10Hz) it is also extremely accurate. But nowadays, i mostly just record the data with the with the Mini Motions in my helmet and use the internal GPS in Logit.
Here is a video from my helmet cam and although the speed talk is not so clear on the runs in the recording due to the cam microphone wind noise, I could actually hear it pretty well on all the runs. But I hold it closer to the cam at the end of the second and third runs when I slow down below 20 knots to hear the 'Last Run' announcement.
I did some analysis on speedruns where I used three loggers@10 Hz, one was mounted on the boom, 2 loggers were mounted on my helmet. As expected in the speedgraphs, there were more "spikes" with the GPS on the boom. But if you look at the speeds, there is only a minor influence ! The boom was not the fastest, as one would expect, but the slowest !
10s boom : 30.132 kn, 10s helmet : 30.197 kn and 30.204 kn
avg boom : 29.575 kn, avg helmet : 29.61 kn and 29.622 kn
This was@Herkingen, a very nice speedstrip which minor chop ! I did another analysis for the "Oesterdam", more the normal chop here, but the same results : mounting on the boom was the slowest speed ! So, for the fastest speeds the helmet position is the best !
In the screenprint, the blue plot is the one @ the boom, green and red are on the helmet.
Select to expand quoterp6conrad said..
I did some analysis on speedruns where I used three loggers@10 Hz, one was mounted on the boom, 2 loggers were mounted on my helmet. As expected in the speedgraphs, there were more "spikes" with the GPS on the boom. But if you look at the speeds, there is only a minor influence ! The boom was not the fastest, as one would expect, but the slowest !
10s boom : 30.132 kn, 10s helmet : 30.197 kn and 30.204 kn
avg boom : 29.575 kn, avg helmet : 29.61 kn and 29.622 kn
This was@Herkingen, a very nice speedstrip which minor chop ! I did another analysis for the "Oesterdam", more the normal chop here, but the same results : mounting on the boom was the slowest speed ! So, for the fastest speeds the helmet position is the best !
In the screenprint, the blue plot is the one @ the boom, green and red are on the helmet.
The boom-mounted unit has higher error estimates than the helmet mounted units, which matches that the graph has more or larger spikes. It has 1-2 fewer sats, which reflects the body blocking some GPS satellites. In general, the u-blox based units seem to have a very slight tendency towards lower speeds for worse signals, which is what most of your results also show. But that's just a general tendency, it's easy to find examples that go the other way (for example 1852 m #4 in your table).
Select to expand quotedecrepit said..
How did the alphas compare, that's where I'd expect the greatest difference
For the Alfas, more or less the same : Error nr. are a bit higher, the speeds are almost the same (Herkingen, first speed is on the boom) :
alpha500 1 22.487 0.027 16:25:55.700 22.506 0.023 16:25:55.700 22.497 0.018 16:25:55.700 (diff = 0.021 knots)
alpha500 2 22.456 0.027 16:28:40.300 22.454 0.023 16:28:40.300 22.466 0.019 16:28:40.300 (diff = 0.012 knots)
alpha500 3 21.673 0.023 14:29:23.900 21.683 0.024 14:29:23.900 21.560 0.020 14:29:24.000 (diff = 0.123 knots)
After all, the conclusion is the same :
Head mounting (helm) gives the superior signal quality !
More sats are visible with head mounting
Error numbers are smaller with head mounting
Boom-mounting will not give higher speeds !
Plot of the best alfa :
Yes, the dip in the blue line just before min speed, is what I was expecting as the rig rotates, but it doesn't seem to affect things too much in that case.
Cool project rp6conrad. A penpal posted me a ESP32 at the start of the year. Out of boredom, I pulled it out a few weeks ago, and have started a blue tooth audio vocoder as my silly f*** around winter project to kill some time. The Bluetooth SDK code for this micro is broken, but that's my challenge
You sampling at 10Hz ?. With the chop noise, you could filter it with finite impulse response filter (FIR). The ESP32 will run it with change to spare. Write a 5 pole Butterworth with a cutoff frequency of about 2Hz and see how the data looks. Do it with recorded data first and look at the graphs. You don't have to embed it until you have something that works. if it's still no good, then set cutoff frequency to 1Hz, and reprocess.
Good luck !. I'll be watching
All these analysis are just for the quest to the most accurate speed measurement ! So the spikes on the speed graph are more a "theorytical" issue ! As we compare (and display on the epaper) the 2s, 10s, avg 5*10s, the mile and so on, these spikes are of no influence on the results. For logging, we never filter these values, as they are straight from the ublox / gps. Filtering is done later on the site (GPSresults) or with other software.
But you are absolutely right, the ESP32 can filter these values for breakfast ! The only issue is with logging to the SD card (SPI), @10Hz we need already a class 10 SD to log 100bytes every 100 ms. With a slow card, you get lost points.
BTW, if bandwidth is an issue, why not compress the stream with gz library ?. The ESP32 is probably equivalent to a Intel Pentium in the late 90s, so no problem with horse power.
Finally did an actual comparison run today with Jan's machine versus GW60. GW60 was right wrist and Jan's on chest as didn't have time to get a better mount sorted. Was pretty excited to see a PB on the epaper on the water but conditions were pretty bad (i.e choppy and gusty) so didn't believe it....sure enough though the results match the approved device fairly closely.
Received the $11 wireless usb charger and tested it on many other things with good result. Only connected it after this run and it worked fine. ..fine being it didn't blow the board. After 20 mins voltage on display (when awake) was 4.18V (from photo at 4.05) so definitely charging. (the box is there holding the Rx as the Rx antenna is directional and the cable is twisted)
Tried Wifi FTP on my daughters **** 5 year old $200 Windows HP Stream and WiFi file xfer worked first time. Spent 3hrs+ ( a few weeks before) with Mac on every FTP program I could find and none worked and one app crashed the esp every time. With Wireless charging and Wifi file management (except with Mac) this thing has potential.
blue is GW60 on wrist, red is Jan's machine
I think you have that back to front Flex, red is the GW60 and blue Jan's machine.
Well that's how it looked here, the GW60 has much worse +/- numbers.
Select to expand quotejn1 said..
BTW, if bandwidth is an issue, why not compress the stream with gz library ?. The ESP32 is probably equivalent to a Intel Pentium in the late 90s, so no problem with horse power.
@10Hz, bandwidth is just enough. Compressing the data could work, but I believe the issue is more with open file, write 100 bytes (1 navpvt sentence) and closing file. Maybe if you only write every s, compressing the 1000 bytes would make a difference.Select to expand quoteFlex2 said..
Received the $11 wireless usb charger and tested it on many other things with good result. Only connected it after this run and it worked fine. ..fine being it didn't blow the board. After 20 mins voltage on display (when awake) was 4.18V (from photo at 4.05) so definitely charging. (the box is there holding the Rx as the Rx antenna is directional and the cable is twisted)
Tried Wifi FTP on my daughters **** 5 year old $200 Windows HP Stream and WiFi file xfer worked first time. Spent 3hrs+ ( a few weeks before) with Mac on every FTP program I could find and none worked and one app crashed the esp every time. With Wireless charging and Wifi file management (except with Mac) this thing has potential.
Great to hear that you succeeded with the wireless charging. Gonna try again here with my device now ! For the blue/red curves, I hope that the blue one is the DIY logger, as normal I have sAcc values of around 0.5. Also the sample rate seems to be higher on the blue curve (10 Hz ?), wher the GW60 has max 5 Hz.
The issue with FTP on Mac is a problem, I dont have access to a Apple system to try things out. But if a search the Internet, it looks that Apple only allows s(secure)ftp transfers. This could be the reason.
After a month without any wind, weather here is changing. Yesterday, there was extreme rainfall (>100 l/m?) in some areas, but also the wind is back again. Hope for some surfing next saturday, now I am in France on holiday. Greetings out of France !
As for the colours above I posted what Decrepit sent me after quickly looking at the files.
Files and colors:
GPSLOG.SBP - blue
BN280A000.ubx - red
Probably worth mentioning that both GPS were mounted very sub optimally. GW60 was worn backwards with face looking to water. Jan's system was floating around loose in box on my impact vest on chest and my van keys in their water proof pouch stuffed on top.(as I was in a rush and had better things coming didn't bother doing better) Did another comparison today but still both not optimal. See photo after session today which was fairly rough (includes the wireless charge system which you can't see at bottom). I had initially stuffed the GPS on one side facing up with the display facing forward but a few minutes on water and a few crashes it was all over the place. Worried that this might short out something. Need to stuff a whole lot more bubble wrap in or mount properly for future missions.
This was the wireless charging system I bought which seems to work well. Make sure you buy the one with the cable going the right direction out of the USB. Has about the same footprint as the Lilygo TT5 epaper so easy to fit in same box. Claims to give 1amp at 5V but whatever the reality it charged the battery to 4.22V (full) no problem in a few hrs.
www.ebay.com.au/itm/183109373716?var=691850324123
The FTP is no big deal as works fine on the lowest end PC available. Long term would be nice if Mac could do it but certainly not a big deal compared to all the good bits.
Select to expand quoteFlex2 said..
As for the colours above I posted what Decrepit sent me after quickly looking at the files.
I obviously opened mine in reverse order to you. What I sent was an example of how to determine which colour was what
Select to expand quotedecrepit said..
I think you have that back to front Flex, red is the GW60 and blue Jan's machine.
Well that's how it looked here, the GW60 has much worse +/- numbers.
Keep in mind that you cannot directly compare u-blox and Locosys +/- numbers - the Locosys numbers will generally be higher (except when stationary). In the graph, the actual spikes are comparable between the two devices (if you take into account that 5 Hz data will look a bit smoother than 10 Hz data). If Locosys SDoP and u-blox sAcc numbers were similar, the spikes for the GW60 should be much more pronounced.
In u-blox data, it is quite rare that you see sAcc values of 1 or higher without a crash. In Locosys data, such higher values are pretty normal. Here's a comparison of GW60 data vs. Motion data that shows what I describe:
The error estimates (SDoP) for the blue GW-60 data are higher than for the red Motion data. But the Motion data show more pronounces spikes, and the actual measured error (vs. the median from 7 different GPS units) was higher for the Motion.
It's pretty cool to see Flex building a prototype from Jan's design, though, and get decent data with it!
You right Decrepit, I had colours backwards. First time using GPS Speed reader to compare files. Next run will ensure the GPS is fixed securely so doesn't float around which is probably the reason for the spikes.
Select to expand quoteFlex2 said..
>>> First time using GPS Speed reader to compare files. >>>
You'll really like it once you get used to it.
Today, I had a low wind summersession on my homespot. The two left loggers (BN220)were on the boom, the two on the right(BN280) were on my helmet. The avg from the 4 devices were very close as you can see. All values recorded @5 Hz, in km/h.
The max 2s had a little more deviation, but on the helmet again very close !
Crashed into a submersed tree, had some sail damage. On the e-paper, you can see some ghosting. This is @power off, the screen will be refreshed every hour. After 10 refreshes, it looks better. Normal screen has almost no gosting.
I'd ordered some of the cute little waterproof boxes Jan is using but they are taking forever to arrive so figured I'd try 3D printing some waterproof boxes while waiting. Have a few designs in progress but the first to be ready for real world testing was the boom mounted version. Like Jan I figure you can buy at least 7 of these for the price of one GW60 so can sprinkle these around even if some positions won't ever be approved. Got everything fitting nicely including the wireless charging mat and was about to silicon and bolt the Polycarb face on when I thought I'd give it a quick test. Zero sats?? The GPS wasn't getting any lock (no red led flashing). This was a well tested working unit with up to 21 sats at times. I removed it from the box and it worked fine and put it back in and same result. Was it the material I 3D printed with? I left the GPS in the box but the board out and it worked fine...put the board back in after getting lock and it kept working. Then put it to sleep, then wake and try re acquire lock...zero sats again. WTF? Tested it with another unit sitting on top of my roof (as per picture) with free unit getting 16 sats and the boxed one 0. Then I realised the Wifi antenna of the TTGO T5 was very close to the GPS antenna and was interfering whilst getting lock, once lock had been acquired it seemed to keep the lock (Jan's software might also be doing less wifi stuff once GPS acquired). To rectify I have to flip the GPS to the other side of the display. I wanted the GPS mounted this way as seeing the Leds on the GPS board is useful knowing that everything is working, but especially when putting the system to sleep with the magnet. The other thing to note if anyone else following along is the wireless charging mat I used appears to be 46mm x 70mm but in reality the coil is only 29mm x 44mm (you can cut or fold away the excess material) so much smaller than the display. You can also cut the on/off switch which isn't used saving 2mm. It means should be able to reduce the next print size.
Can you shield the gps from the wifi? a bit of tin foilf connected to earth (-ve rail) should do it. In fact an earth plane around the bottom of the BTN280 could improve everything.
Great printed enclosure, love it!
In my software, the Wifi radio of the esp32 is active as long as there is a connection with a Wifi network ! (Screen says "Wifi On" + IP-adress). As soon as the connection is lost(screen "Wifi Off"), or after a 10 s search by booting, the Wifi radio is switched off completely. Reason is current consumption and GPs-interference.
How did you manage to seal the 3D printing housing ? I didn't see a sealing ring. Is the 3D print tight on its own ? I did some testing in this direction, but the sealing is not evident !
I would worry about foil as there are lots of bare pins floating around. Better to move the GPS away from antenna. Can play with foil later if required. Attached is one version on the printer now with GPS as far away as possible from wifi (this one for helmet mounting). Another version has the GPS next to the SD card which will minimise the overall size of unit but the GPS will be 20mm from Wifi.
Interesting Jan, maybe its the antenna shape?? For sure the system never got more than 3 sats for a few seconds in that config despite leaving on the roof for 20mins. As soon as move the board away it works fine and once it gets sats they seem to stay. I've noticed weird interference stuff going on with other GPS stuff, wireless bike speedos, iPhone's etc that I've stuck on my bike handlebars over the years. As for the sealing you can probably see in the image above I've stuck a small lip in, this really to try and stop silicon leaking inside when I tighten the bolts. Originally I was printing this in "Flex" material but even with lots of ironing it wasn't that smooth (as per photo from an early prototype). I've made other projects without lip that seal just fine with silicon and bolts and have not leaked for years...of course not subjected to high impact like to be expected in this application. Might use this reject print as a pressure test case and dump it in the pool (or sink it into the river with some crab pots..if it doesn't leak at 25m static it will pass I figure)
Select to expand quotedecrepit said..
Can you shield the gps from the wifi? a bit of tin foilf connected to earth (-ve rail) should do it. In fact an earth plane around the bottom of the BTN280 could improve everything.
Great printed enclosure, love it!
The way the Beitian units are set up, they have an small ground plane right below the antenna (somewhat similar to the mesh used in the GW-60). You'd get an improvement only if the ground plane extends beyond the sides of the BN220, ideally by at least a couple of centimeters.
Love the enclosure, too. Great work, Flex. Once you got a design you like, can you put it somewhere so others without a 3 D printer can order it online?
As for waterproofing, my first thought was to just glue the cover on, similar to the way Julien does with the Motion. For Flex's design, it should be easier to open it up later, and replace the housing, if that should become necessary.
Yes, glue is an option but I assume I will want to fiddle/change. Assuming any design actually works I have no prob sharing the files...a bit early yet though to say any of this is worthwhile. You could then ask someone like www.prusaprinters.org/world (at least 3 in Perth) or some other print farm to print for you but all will want costs + labour. To 3D print water proof takes time (10hrs) so cost for others to do for you will be high I guess. If you are remotely interested in doing this you are better off either getting your own printer or just get the little boxes like Jan's ($8.92AUD delivered here in WA, but very slow). This the Ebay link (probably cheaper on Aliexpress) for the box www.ebay.com.au/itm/183702626721?hash=item2ac587a1a1:g:JUMAAOSwaohbKMQp
Bit more progress today. Attached pics of the boxes with two different GPS positions. One as far away from Wifi antenna as possible (left with boom mount) the other making the unit as small as possible (Gopro mount)...both with leash attachment. Right one has the wireless charge mat in but other not. Unit on left has the reed switch underneath board next to wifi antenna which gives a cleaner look (and still works fine) I also finally got my bottle of Dichloromethane (intended for another project) so printed the right one without bolts togluethe polycarbonate face on as per a previous suggestion. Since the only way to separate this bond is destructive its glued without electronics for a first pressure test. The glue is setting now, will resist temptation to test today and let the bond harden overnight as the bolt on silicon test failed today (2nd and 3rd pic). Whilst I only left the silicon to cure for 5 hrs and was at bottom of pool for a few hrs (at 2m) I think the leak happened at the rear of unit, not on the face seal as I stupidly recessed the nuts making a small area at each nut very thin walled and under high pressure from the bolt tightening. (I may be wrong of course) So yet another bolt on print to follow without nuts, but smaller holes for the thread to bite to see if this concept works in real world. Plus another glue on version with 4mm walls versus 6mm in pic...assuming the pressure test works. Thankfully each print is only about $1 and fully recyclable PETG.
Select to expand quotemathew said.. ^^ ... I see a problem... 
I think it's possible, that once flex resolves the water ingress problem, he may just cut the excess thread off those bolts.
ya, I didn't cut the bolts as I want to reuse them as this just a prototype. Needed 25mm bolts but of course the local hardware store were out of stock in that size so had to use 35mm. I'm liking the glue on option though. I stuck the first test at the bottom of pool yesterday and pulled it out 11hrs later. Still water ingress. Hard to see the water in the photo. Hard to know exactly where the water is getting in, most likely the seams and/or the corners (plus I had a layer shift you can see 1/2 way which probably didn't help) but have tweaked the design a bit and print settings and try again. Want to get the raw print as water tight as possible before doing post process like painting, epoxy etc..
