Looks like your software is now much better Jan. Since no wind I ran 4 units on my dash, drove to my location, left them all with clear view of sky then drove home for a total of for nearly 5 hrs recording. Zero data errors on any unit. Compares well to yesterdays test where three units were still getting some write errors after formatting the cards. SD cards I used were Sandisk UltraPlus 16G and Sandisk ExtremePlus 32G (total overkill for application) Of course we have no wind for a while so will be some time before a real world test.
Made some good progress with waterproofing 3d print today. Tried two samples with glue on face with 5% and 10% over extrusion PETG. The 5% failed the 1m water depth test but the 10% was rock solid. Tried the 10% at 2m water depth and got 1 tiny drop entry after 20mins. Print quality was still good so will try 15%..getting close now
Matt: Conrad is using the SD code via a FATfs file system layer. As you said, SD cards are block devices, but file systems do clever tricks to make a block device look like a character device, with what you said in mind. Unfortunately, the fatfs library is a complied object, and I can't see the code on my system, but I'm guessing that it is clever, depending how much effort Espressif have put into it. There is only one way to find out:
Conrad: the SD library you are using lives here (well, on my system):
~/.arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/SD
I recommend you backup this directory and then add some debug serial printf() statements into this library. Then write a small test program to write a byte of data with your open() write(1 byte) close() convention, and then see what it does. Then write another program that writes two bytes: open() write(1 byte) write(1 byte) close() etc.
I recommend putting some printfs in sdReadBytes(), sdWriteBytes(), sdReadSector(), sdReadSectors(), sWriteSector(), and sdWriteSectors(). These are located in sd_diskio.cpp in the directory (folder) above.
What you want to know is:
- if I write a byte, is the file system reading 512 bytes and then writing 512 bytes (a block write) ?
- What happens if I write 2 bytes in a row ?. Does file system do 1 read block and 2 writes blocks ?. Or does it do nothing ? (implying the file system is caching).
Once you gauge what the file system and SD library are doing, you'll be able to write some elegant code that gets your application singing
Matt is right. You should have ooddles of bandwidth.
Filesystems are indeed character devices programmatically speaking - but that encapsulation can never completely hide the real hardware. When I use the phrase "block", I dont mean "block device vs character device", I mean the flash memory is arranged as a block with row-assert and column-assert defining the width/height of memory-cells.
Most modern SD cards have some RAM to coalesce writes, to minimise the effect of tiny-writes vs hardware-blocks. So testing may or may not show the hardware-blocks, and it may even trigger some slow-down at certain write() sizes. The slowing is a latency due to the firmware in the flash, doing its magic.
In any case, the Arduino forums appear to recommend about a 16k application-buffer. I would try 512B, 1k, 2k 4k, 8k, 16k application-buffers, timing them to determine which is fastest per large-data-set (say 1MB)
In my understanding, the SD.h lib has its own buffer, so if you dont flush() or close() the file, the writing is only done when the buffer is full. As I change my sw now, the file stays open all the time. The bandwidth seems to be OK now, even @18 Hz logging (every message is 100 bytes). To prevent data loss (sw crash, battery low), every minute a flush() is done. Files are closed by a normal shutdown.
The 18Hz data rate can only be used as 1 GNSS system is received (ublox M8N), the 10Hz rate can use 2 or 3 GNSS simultanous (GPS, Glonas...).
Greetings, Jan.
chopped the USB plugs off the wireless charging coils I had purchased as too short for easy mounting, scrapped off the insulation and soldered on longer leads. Made all 4 units wireless charging. The boom units had charge coil opposite GPS so can charge whilst on boom and the head/shoulder units at the base of box (as fits easier in box).
The 15% over extrusion 3D print survived 30 minutes at 2m water depth with zero leaks (failed 14hr test though) but figured this is enough for head mounted unit that will endure rain and the odd dunking. So sealed first unit in, (needed a bit of sanding due to the extra plastic to get a snug fit) and probably a bit enthusiastic with the dichloromethane and clamping (bit of plastic creep). Since I changed filament colours again, printed an identical twin to torture test in the pool to make sure (tomorrow plan).
Had suggested Jan provide selectable 'complications' instead of the fixed max current run speed and a few hrs later installed the new software with user selectable best current run, total distance, best session 2sec, best session 5 x 10sec, best alpha. Now no need to stop to see your best stat. Since no wind went for a bike ride to test them all out. Attached pic is showing some of the options. The font seems to invert when change direction but Jan can advise what the software is doing with the inverted font.
(ps If anyone is wondering why 4 units show different speeds below its because the real time update on each unit is 2 secs and I'm riding a push bike one handed trying to take photo so my speed is variable)
Julian, I did test the current of the wireless charger at battery voltage 3.8V and was 200mA at 5.1V. Didn't want to test short circuit current in case of blowing something up.
The "inverse" text on the "speed screen" is when the logger detect a new run (big heading change
or speed<1 m/s). This was done for test purposes, but I it is still in.
As Jim (flex2) had a good proposal for changing the "field" with the reed switch, I adapt the sw. It seems to work fine, send the new sw 4.55 to Jim. After the logger has booted, you can cycle through the different choices with a short actuation of the magnet.
Long actuation is still shut down.
Had today a very nice summer evening session @ Herkingen. At the end, the wind was too strong for my sail size. Was on the water with 4 loggers, 2 on my helmet, 2 on the boom. Numbers do correlate very well (avg lowest 58.0 km/h, highest was 58.04 km/h).
Log @5Hz from unit on my helm :
www.gps-speedsurfing.com/default.aspx?mnu=forum&forum=2&val=177226
For boom mounting, the housing has to have a excellent sealing ! When the sail is in the water, the housing is submersed, it cools down and will suck water even in the smallest gap !
To test your housing for leaks, next method gives you the position of the leak :
Prepare the housing so you can close it fast, but it still has to be partially open.
Put the (empty or with electronics) housing in de freezer for 10 minutes. The air in the housing will cool down.
Get the housing out of the freezer, and close it as fast as possible.
Submerse the housing in a (glass) can with hot water in it. The air will rapidly expand.
See the bubbles coming.....
I did this and found a big leak where the sealing is coming together.
Nice one Jan, Might try that cooling technique with the 3D printed box when glueing the lid on to keep a +ve pressure inside the box.
Probably also worth mentioning the screws that come with those boxes are very cheap. Mine started rusting after just two sessions. Looks like yours are also starting to rust. The screws are outside the seals so exposed to the elements. Replaced with 316 screws and greased them to hopefully extend life. The female threads look like brass but could be anything.
>>>>.just need some wind!
Thursday at Yunbas is looking possible, but forecast keeps dropping
Not much wind here recently but enough for a bit of a session yesterday. Decrepit noticed an effect that always occurs during the rig flip on a gybe between the two boom mounted units. I had a 360 camera mounted yesterday and the following video shows why each boom unit reads differently to the head, shoulder and wrist units mid gybe. The accuracy of these devices is pretty impressive that you can see these effects.
Essentially on a right turn the GPS mounted on right boom swings opposite the direction of motion with the greatest radius from the point of rotation (your front hand) during a rig flip. This 'slows' down the speed this GPS is travelling relative to the other units. The GPS on the left boom is close to the point of rotation so doesn't see this effect as much. During a left turn the opposite occurs and the left boom slows down. Depending on your technique the boom closest to you when you initiate a turn can also speed up during the sail flip. When you push the mast forwards to catch the wind after the rig flip both boom mounted units increase velocity at roughly the same amount. If you look carefully at the data with GPSSpeed reader etc you can also see the unhook, the wrist movement and also head movement when clearing the gybe etc if you mount the GPS on the side helmet like in this video. Not very good gybes in this video (first example is garbage) and I didn't clear gybes as was sailing alone but there wasn't that much wind is my excuse.
The optimal position for the head unit is directly on top for best view of sky and least movement. I was playing around with different 360 positions so didn't have the GPS on top for this session.
This is a great analysis and illustrates again how well the 10Hz data for these ublox based devices can show up the micro velocity changes quite clearly. It is an interesting insight to say the least.
We were quite wary that a boom mounted device would not perform very well at all due the the shaking it was likely to get, and possible orientation issues, but we have studied this data and, while it does show a higher degree of sawtooth, it certainly is not as bad as we had feared. Of course, this was relatively flat water as well. Most of the data is well within the error margins of the other devices worn, so it seems there is a cancelling out of velocity changes happening to some degree. I don't think we are ready to recommend posting from boom mounted devices just yet, but with more data that could change.
It has turned out to be quite an enlightening experiment. Thanks Jim!
Just found this thread and keen to construct one. Thanks for all your hard work Jan and you other guys offering input.
I was thinking the 3D printed case may always have the inherent problem of moisture absorption, given the way 3D prints are created layer by layer. I've looked at prints i have made under a microscope and they definitely look like water could find it's way in. A shame as seeing the initial post had me thinking i'd print a case.
I've only got an old Locosys BGT-11 i think it is currently, so keen to see how this goes.
>>>
I was thinking the 3D printed case may always have the inherent problem of moisture absorption, given the way 3D prints are created layer by layer. I've looked at prints i have made under a microscope and they definitely look like water could find it's way in. A shame as seeing the initial post had me thinking i'd print a case.
I've only got an old Locosys BGT-11 i think it is currently, so keen to see how this goes.
So a sealing coat over the the outside?
Great to have more interest, the more people involved the better it'll get.
A short vid of boom mounting with a elastic band :
You right, the 3D prints don't seem brilliant at being fully water proof. I followed Prusa's water proofing guide and managed to get a print to survive 2m depth for an hour but despite that, after 4 sessions there was some moisture inside the case. Storing it inside a bag of rice for 24hrs got rid of the moisture but long term it doesn't look great solution. Figured I might try subtractive instead of additive manufacture and CNC these out of bits of poly carb. 2 bits of 12mm plus the 3mm face give the same dimensions as the 3D printed one. Rough sketch as below.
I had a big prang the other day and catapulted due to grounding out on a sandbank. Bent the boom. The boom GPS seemed to survive and got a few more hours use out of it and managed to turn it off, then on again to download. Getting ready for tomorrows session and trying to load Jan's new software on this boom unit but wouldn't turn on. Opened case and despite looking ok the reed switch glass had cracked. This was my first working unit and the only one I had the reed switch on top of display (wedged between the T5 and the box face). Can't be sure but figure the reed switch is probably better mounted like all the other units either beside or behind the wifi antenna so will receive less force in a crash. The box also lost one press fit female threads in the crash, there seems to be a stack of them one on top of the other. Other than the reed switch the units seem to be able to withstand a decent prang.
I had a big prang the other day and catapulted due to grounding out on a sandbank. Bent the boom. The boom GPS seemed to survive and got a few more hours use out of it and managed to turn it off, then on again to download. Getting ready for tomorrows session and trying to load Jan's new software on this boom unit but wouldn't turn on. Opened case and despite looking ok the reed switch glass had cracked. This was my first working unit and the only one I had the reed switch on top of display (wedged between the T5 and the box face). Can't be sure but figure the reed switch is probably better mounted like all the other units either beside or behind the wifi antenna so will receive less force in a crash. The box also lost one press fit female threads in the crash, there seems to be a stack of them one on top of the other. Other than the reed switch the units seem to be able to withstand a decent prang.
Hall effect switch may be a better option than the reed switch, being solid state. Would just require a tweak in the code to see the switch change of state.
I had a big prang the other day and catapulted due to grounding out on a sandbank. Bent the boom. The boom GPS seemed to survive and got a few more hours use out of it and managed to turn it off, then on again to download. Getting ready for tomorrows session and trying to load Jan's new software on this boom unit but wouldn't turn on. Opened case and despite looking ok the reed switch glass had cracked. This was my first working unit and the only one I had the reed switch on top of display (wedged between the T5 and the box face). Can't be sure but figure the reed switch is probably better mounted like all the other units either beside or behind the wifi antenna so will receive less force in a crash. The box also lost one press fit female threads in the crash, there seems to be a stack of them one on top of the other. Other than the reed switch the units seem to be able to withstand a decent prang.
Hall effect switch may be a better option than the reed switch, being solid state. Would just require a tweak in the code to see the switch change of state.
The hall switch has more "sleep current", as the reed switch has none. The "sleep" current now is 0.5 mA, so with the 2000 mAh lipo it will last sleeping for max 4000 h.
Been following this project for a bit and ordered some parts.
I just returned from my windsurf holiday, finding some of the parts in my mailbox. The board and the gps unit have arrived. Soldered the connections. First made the mistake of connecting the gps serial outputs to the boards serial ports. Than I read this thread and saw there was a good reason not to. After fixing this, the solder work was done, piece of cake. I have the Beitian BN-280 gps module which comes with two extra connector cables. I put a heat shrink around those to avoid shorts.
Formatted a suitable SD card, put the config file on it. Wasn't familiar with flashing bin files using the OTAwebupdater, but Jan pointed me in the right direction. First I had to set the correct Baudrate (115200) when using the serial monitor in the arduino ID, or else the data was not readable. Than the IP showed up which could be used to flash the bin file to the board via a browser, using the OTAwebupdater that was installed onto the board. Installation completed!
The battery is still at the post office, waiting to be collected, so I did a test drive today, on the bike, connected to a powerbank. Downloaded the data using FTP. The data looks reliable in gpsspeedreader, and I had a good satellite fix. Planning to connect a QI receiver so I can kit the box and leave it closed.
Thanks for this project Jan!
ok brainiacs out there. Took a bit of time but scrounged a nice offcut of 25mm acrylic and machined a box with exact dimensions as the 3D printed one. Glued (CH2Cl2) a poly carb lid on, let cure for 24hrs and chucked it in the pool at 2m depth for about 8hrs. Same leakage as the 3d prints...wtf? Must be leaking at the glue joint?? Photo #1, raw machined 25mm acrylic, #2 with lid glued, #3 straight out of pool then put it on the bench, within a few minutes ALL water had drained out (#4)!! How is that possible? I didn't seal with positive pressure but anyone care to say why a few ml leak in over 8 hrs under pressure but leaks out in minutes with no pressure. Doing my head in. All I can think is I didn't put glue all around but sure thought I did??
Your troubles getting something waterproofed reminds me of when we talked to the guy who developed the Flysight GPS (a 5 Hz ublox GPS with clever firmware, a few years ago). He was quite interested to develop a version with display for windsurfing, but the project died when he talked to engineers about waterproofing. He got an estimate somewhere in the range of $50K - $100K, IIRC.
Maybe assembling everything in one of your boxes, and then adding a layer of fiberglass and epoxy on the outside that covers the seems, is the most pragmatic solution. You could just let Mike do it .
Sitting at bottom of pool with small leak, the internal pressure would've equilibrated to the 2m head of pressure once a certain amount of water had entered (probably happened pretty quickly and not over the whole 8hrs). Upon removing from pool the internal pressure is then "2m water head" higher than external pressure and pushes water out pretty quickly.
ya Jetlag, that's what I thought initially but water molecules are bigger than air (at least I think so) so you would think the pressure would push more air out and just fill the box with water. If what you say was going on (which implies the box is airtight not water tight which seems weird) Boyles law (P1V1=P2V2) I think shows the volume of water to air should be about 50/50 at 2m water depth (ignoring temperature effects which are small in comparison)
At 2m water depth the pressure is nearly 18psi higher than at the surface. The box is sealed at atmospheric pressure 14.7psi so the pressure at 2m is 18psi +14.7psi or 32.7psi. Vair at 2m = Vair at surface * 14/7/32.7 = 0.445. (maybe my calc is wrong?). However you can see in the photo the amount of water is around 5%, certainly a lot smaller....the odd thing is its also about the same as the leakage with 3d printed cases, both glued and siliconed/bolted. Certainly does my head in.
Played around a bit with this one in the pool and watched it carefully. While running to the bottom of the pool no air escapes, when bringing the case back to surface a clear string of bubbles come out and there is water inside. Repeating the trip to the bottom of the pool results in same, no air escapes but coming out a stream of bubbles..continuing this up and down results in the box filling with water very quickly. I think there must be gaps in the glue seal and the result is some sort of valve, the pressure at the bottom holds the lid tight and there is no water entry, can sit there a long time but when the outside pressure reduced, the seal breaks and air comes out/water goes in.
Calculation previously was wrong. Pressure at 0m =14.7psi, pressure at 2m is 17.6 psi so ratio of volume is 14.7/17.7 = 0.83 (or should be about 17% water entry).
pretty sure this particular leak is poor gluing related problem. Tried rotating unit in different dimensions, both in the pool and draining it. With one edge up it does not leak at all, and that same edge facing down on the bench the water doesn't leak out, another two edges show very slow leak and can get it in and out of pool without leaking if go very slowly, but if pull out fast they still leak. One edge leaks like a sieve, but again only when pulling out of the pool. Never leaks whilst going in. Have CNC'd another box and this time cleaned all the surfaces with iso and gone extra crazy with the glue to see if any changes.
Played around a bit with this one in the pool and watched it carefully. While running to the bottom of the pool no air escapes, when bringing the case back to surface a clear string of bubbles come out and there is water inside. Repeating the trip to the bottom of the pool results in same, no air escapes but coming out a stream of bubbles..continuing this up and down results in the box filling with water very quickly. I think there must be gaps in the glue seal and the result is some sort of valve, the pressure at the bottom holds the lid tight and there is no water entry, can sit there a long time but when the outside pressure reduced, the seal breaks and air comes out/water goes in.
Combine that with what Jetlag said. At the bottom, the pressure pushes the top plate down so it is almost tight, but a tiny bit of water is pushed in reduce the pressure difference. You don't need much, and the water may remain as gas rather than as droplets. Then when you go back up to the surface, the inside has excess pressure, which lifts the top plate, allowing bubbles to escape and larger amounts of water to get in.
The solution is that you need a compressible layer. The "waterproof" thingies I have opened usually had a rubber band. That still got them only to IPX6 or 7, which is less stringent than your tests. Better machining and smoothing may also be needed, but without a compressible gasket, you'd have to reach smoothness in the molecule-size (nanometer) range everywhere.
I think all this illustrates why Julien chose to seal the Motion houses permanently.