Each record in an Locosys .sbp file is 32 bytes, compared to 52 bytes in Motion .oao files and 100 bytes in .ubx files. So with respect to file size and transfer speeds, .sbp files would be the best choice.
The primary reasons not to use .sbp files are:
(1) Loss of resolution. Speeds are saved with in increments of 0.02 knots (0.01 m/s, to be exact), while .ubx and .oao files use increments of 0.002 knots. This introduces a potential rounding error of 0.01 knots. Similarly, error estimates (SDOP) is written at lower accuracy and with a more limited range.
(2) No checksums. Unlike the other formats, .sbp files do not have checksums that enable software to detect file corruption, which can happen during recording (think of the ESP chips that do not boot up anymore - that is because memory corruption is detected through checksum errors) or during file transfer (rare, but I have seen examples of this happening).
All formats, including .sbp, contain some data that are not used when calculating speed or displaying tracks. They can useful for special purposes like device validation, but usually are completely ignored. With regards to extra data for special purposes, the .ubx format is a clear winner, since it can support storing many other data items, like detailed satellite information (UBX-NAV-SAT sentences). But this does not matter for routine use.
For speed analysis and track display, the following information from .sbp files could be omitted:
- SVID_LIST (4 bytes)
- ALTITUDE (4 bytes)
- CLIMB_RATE (2 bytes)
- VS_DOP (1 byte)
However, the following changes would be advisable to avoid loss of accuracy:
- save doppler speed as 4 bytes instead of 2 bytes
- save SDOP as 2 bytes instead of 1 byte
- add a checksum (1 or 2 bytes) to catch file corruption or manipulation (e.g. manual editing of speeds)
Two additional changes could be considered:
1. A "record type" indicator to make the format expandable (1 byte)
2. Omit the HDOP data (1 byte). Theoretically, HDOP filters are still used, but in reality, data with HDOP numbers high enough to trigger filters will also trigger accuracy and/or satellite filters.
With the changes above, the record size could be reduced to 32 - 11 + 5 = 26 bytes, give or take a couple of bytes. That would be half the size (and transfer times) of .oao files, and about 1/4th of the .ubx file size - without the loss of resolution that using the .sbp format would bring.
The logical thing to do would be to define a new file format with the changes outlined above. The new format would be more compact than any existing file formats, but have a higher resolution/accuracy than the .spb format. In the context of the ESP logger, it would be easy enough to log data in both the new format and a format that is already supported until analysis programs and web sites are updated to support the new format. The file format definition could easily be accompanied by example code for reading files in the new format in different languages (Java, C, Python) to make adaptions easier.
As for GPS Speedreader, I'd be perfectly happy to add support such a new open source format, and to participate in discussions to define it.
Select to expand quoteboardsurfr said..
Each record in an Locosys .sbp file is 32 bytes, compared to 52 bytes in Motion .oao files and 100 bytes in .ubx files. So with respect to file size and transfer speeds, .sbp files would be the best choice.
The primary reasons not to use .sbp files are:
(1) Loss of resolution. Speeds are saved with in increments of 0.02 knots (0.01 m/s, to be exact), while .ubx and .oao files use increments of 0.002 knots. This introduces a potential rounding error of 0.01 knots. Similarly, error estimates (SDOP) is written at lower accuracy and with a more limited range.
(2) No checksums. Unlike the other formats, .sbp files do not have checksums that enable software to detect file corruption, which can happen during recording (think of the ESP chips that do not boot up anymore - that is because memory corruption is detected through checksum errors) or during file transfer (rare, but I have seen examples of this happening).
All formats, including .sbp, contain some data that are not used when calculating speed or displaying tracks. They can useful for special purposes like device validation, but usually are completely ignored. With regards to extra data for special purposes, the .ubx format is a clear winner, since it can support storing many other data items, like detailed satellite information (UBX-NAV-SAT sentences). But this does not matter for routine use.
For speed analysis and track display, the following information from .sbp files could be omitted:
- SVID_LIST (4 bytes)
- ALTITUDE (4 bytes)
- CLIMB_RATE (2 bytes)
- VS_DOP (1 byte)
However, the following changes would be advisable to avoid loss of accuracy:
- save doppler speed as 4 bytes instead of 2 bytes
- save SDOP as 2 bytes instead of 1 byte
- add a checksum (1 or 2 bytes) to catch file corruption or manipulation (e.g. manual editing of speeds)
Two additional changes could be considered:
1. A "record type" indicator to make the format expandable (1 byte)
2. Omit the HDOP data (1 byte). Theoretically, HDOP filters are still used, but in reality, data with HDOP numbers high enough to trigger filters will also trigger accuracy and/or satellite filters.
With the changes above, the record size could be reduced to 32 - 11 + 5 = 26 bytes, give or take a couple of bytes. That would be half the size (and transfer times) of .oao files, and about 1/4th of the .ubx file size - without the loss of resolution that using the .sbp format would bring.
The logical thing to do would be to define a new file format with the changes outlined above. The new format would be more compact than any existing file formats, but have a higher resolution/accuracy than the .spb format. In the context of the ESP logger, it would be easy enough to log data in both the new format and a format that is already supported until analysis programs and web sites are updated to support the new format. The file format definition could easily be accompanied by example code for reading files in the new format in different languages (Java, C, Python) to make adaptions easier.
As for GPS Speedreader, I'd be perfectly happy to add support such a new open source format, and to participate in discussions to define it.
Happy to hear that you are willing to participate in this "side" discussion ! Another rather simple possibility for a smaller size is use of "differential" long and lat fields : normally you have 4 bytes for long and 4 bytes for lat. You could easily calculated the difference between two frames, and store the difference in 2 bytes. 4 bytes less.
The "record" byte can be used to identify a "complete" frame, or a "differential" frame.
The format should be :
- open source
- easy to implement on ?-controllers
- easy to understand
- expandable ("record byte")
- as small as possible, but lossless compression
- widely accepted in the community (GP3S, GP-Sar, GP-Results, GPS Speedreader, esp-gps, gyro-1.....)
Greetings, Jan.
Select to expand quoterp6conrad said..
Another rather simple possibility for a smaller size is use of "differential" long and lat fields : normally you have 4 bytes for long and 4 bytes for lat. You could easily calculated the difference between two frames, and store the difference in 2 bytes. 4 bytes less.
The "record" byte can be used to identify a "complete" frame, or a "differential" frame.
The format should be :
- open source
- easy to implement on ?-controllers
- easy to understand
- expandable ("record byte")
- as small as possible, but lossless compression
- widely accepted in the community (GP3S, GP-Sar, GP-Results, GPS Speedreader, esp-gps, gyro-1.....)
Agreed - although the last item is not something that can just be decided. Having a good description, and "use if as you wish" license, and example code should help, and contacting the various developers before the format is "written in stone" may also help.
As for your example of compression, the same idea could be applied to date/time (possibly saving another 4 bytes), and possible to other data fields. The drawback is that it leads to somewhat more complicated code, and thus goes a bit against the "easy to understand" and perhaps "widely accepted" requirements. But it it certainly something worth discussing. I think the detail discussion should perhaps be done somewhere else - maybe over Github or email?
I'll take your replies without addressing the offer as a refusal and withdraw the offer. Don't forget to remove the OAO related stuff from your Github, thank you. One of these terms was a deal breaker hu.
Select to expand quoteJulienLe said..
I'll take your replies without addressing the offer as a refusal and withdraw the offer. Don't forget to remove the OAO related stuff from your Github, thank you. One of these terms was a deal breaker hu.
Dont forgot to copyright your oao file format on your site , so nobody else wil make this stupid mistake as I did !
Select to expand quoterp6conrad said..BigBoss said:
Hi Jan,
I noticed that the logo choice number does not responded correct to the logo's. Logo choice 12 should give Gaastra and Fanatic, but it displayed Fanatic and duotone.
Other issue, i want to change the timezone, but when i submitted the browser say that the 'barlenght' must be more than 1000 ( i had 500). Oke i changed it to 1000 then GPIO12_screen should be less than 1000.
The fieldchecks looks a little off ;-)
I did just checked the logos, on my browser (chrome / win10) everythings looks fine. Just the saillogo's 3 and 4 (both NP) were in reverse order. Logo 12 should display Fanatic and Duotone (board logo 1, sail logo 2).
The barlength is now limited between 1000 and 1852 meter, but I can enlarge this window from 250 - 10000 (can be handy in the Defi wind...). Timezone did work for me as it should. Only the change of the logOAO field was rather difficult, probably due to missing credits....
(sorry for the joke, i could not resist...).
Here the corrected logo list :
Hi Jan, Yes changing the timezone works perfect, but it wont submit the changed value due the fieldchecks on the barlenght and GPIO12. If you download the config.txt, edit the config.txt file and upload it again, there is no fieldcheck (duh). So it can be 500... i think you understand me.
Logo's
Wel on my two devices the logos are as i decribed. So only the sail number (digit 2) determined the logo. I mean, 11, 21,31,41,51,61,71,81,and 91 result all in Starboard en Gaastra.
12,22,32,42,52,62,72,82 and 9,2 all result in Fanatic Duotone
Peter and Jan. I love this, open source format, designed for windsurfing GPSs. Wish I could help, but all I'm good for is bug finding.
Select to expand quoteK888 said..Freezer said..
Would be nice to see if we can add support for the good old .sbp format again. File size is then even further reduced and is already accepted as input for GPSspeedsurfing.com
It is worth bearing in mind the SBP format doesn't support some of the interesting u-blox outputs such as horizontal, vertical and heading accuracy. SBP also has a lower precision than the u-blox outputs (e.g. cm vs mm, cm/s vs mm/s). Recording in SBP would mean that potentially useful data is gone forever.
SBP also supports some things that the u-blox does not output so that is a bit of wasted space; e.g. climb rate accuracy (aka vsdop).
Anyone interested in the content of various the file formats (including SBP, SBN, OAO and UBX) can find it on page that I created a little while ago. The gps-wizard project itself is very much a work in progress but the documentation on the various formats is accurate.
Click the formats themselves for details - logiqx.github.io/gps-wizard/
I would definitely appreciate additional fields for additional sensors like accelerometer, gyroscope, magnetometer, barometer and temp. Although for speedsurfing some would only be interesting to see how we crash, but I expect for wave and jumps this would make sense. Perhaps also ANT/BT sensors (heart-rate) might make sense. Not sure how much trade-offs you have to make to make it flexible (small in compact when possible, extensive when needed).
Since I have a fair few skills and areas of expertise that are helpful, I created a project on GitHub and done a fairly extensive brain dump.
github.com/Logiqx/open-gnss
TLDR - The documents describe a basis for an open format that supports minimal GNSS content (as proposed earlier in this thread), extensive GNSS content (including other sensors) and anything inbetween.
There is a strong emphasis on compatibility, primarily forward and backward compatibility.
Forward compatibilty = old files continue to work in new software
Backward compatibility = new files work in old software, without requiring software modification / updates.
It's by no means the finished article but I think it should provide a decent basis for discussion.
Select to expand quoteBigBoss said..rp6conrad said..BigBoss said:
Hi Jan,
I noticed that the logo choice number does not responded correct to the logo's. Logo choice 12 should give Gaastra and Fanatic, but it displayed Fanatic and duotone.
Other issue, i want to change the timezone, but when i submitted the browser say that the 'barlenght' must be more than 1000 ( i had 500). Oke i changed it to 1000 then GPIO12_screen should be less than 1000.
The fieldchecks looks a little off ;-)
I did just checked the logos, on my browser (chrome / win10) everythings looks fine. Just the saillogo's 3 and 4 (both NP) were in reverse order. Logo 12 should display Fanatic and Duotone (board logo 1, sail logo 2).
The barlength is now limited between 1000 and 1852 meter, but I can enlarge this window from 250 - 10000 (can be handy in the Defi wind...). Timezone did work for me as it should. Only the change of the logOAO field was rather difficult, probably due to missing credits.... (sorry for the joke, i could not resist...).
Here the corrected logo list :
Hi Jan, Yes changing the timezone works perfect, but it wont submit the changed value due the fieldchecks on the barlenght and GPIO12. If you download the config.txt, edit the config.txt file and upload it again, there is no fieldcheck (duh). So it can be 500... i think you understand me.
Logo's
Wel on my two devices the logos are as i decribed. So only the sail number (digit 2) determined the logo. I mean, 11, 21,31,41,51,61,71,81,and 91 result all in Starboard en Gaastra.
12,22,32,42,52,62,72,82 and 9,2 all result in Fanatic Duotone
Yes, you are right, there is still a bug in the decoding of the logos. I will correct it in the next update.
Greetings, Jan.
Select to expand quote
rp6conrad said..
Yes, you are right, there is still a bug in the decoding of the logos. I will correct it in the next update.
Greetings, Jan.
Don't forget that some manufacturers do boards and sails :)
Also could we have the new files on top?
And of course I'd like a WaveWands logo. (Can anybody do the Lady of the Lake's arm, catching Excalibur before it hits the water.)
There is a new SW 5.60 version with next changes :
* SW5.60 Bugfixes + added sbp file format
* Changed next file for compiling with Arduino IDE 2.02 (SD(esp32) to SD)
* C:\Users\andre\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\SD\library.properties
* Bugfix decoding config logo, GPIO12 and stat_screen
* Range bar_length now from 100 - 10000
* Removed fileformat .oao
* Added new fileformat .sbp
The .sbp format is the old Locosys GT31 format, which is even 70% smaller then the .ubx format. Uploading to GP3S and other sites should be possible, as they accept the GT31 format. As the resolution for speed is here cm/s (ubx = mm/s), very small deviations are possible. If you intend to break the world record, I advise to use the ubx format !! Sometimes it can be a mm question....
@Remery: Changing the order of the files in the webserver is not so simple, as this is beried deep in the sd.h library....
github.com/RP6conrad/ESP-GPS-Logger
Julien has indicated that he regards the .oao file format as something that he has the right to control and to dictate terms.
Therefore, it is possible that I might be forced to remove support for the .oao file format from GPS Speedreader in the future, or that I'll remove it simply because I don't want to waste any time discussing legal issues.Select to expand quoteJulienLe said..
I'm willing to let you use OAO if:
- ......
- This whole agreement is for non-commercial and do-it-yourself use only. Commercial use is explicitly, and with no exception, prohibited.
I strongly suggest that anyone who uses GPS Speedreader should use settings on their GPS loggers to only save in file formats not affected by potential copyright issues. That means to change your settings to log to .ubx files, not .oao files.
Stopping to use the .oao file format (and any future Motion-specific file formats) may even be a good idea if you're using other software or websites like ka72.com, since other software and web sites tend to have a commercial component (license fees or other revenue), which could be construed as "commercial use" of file formats.
Perhaps Julien can clarify whether this is in relation to reading and / or writing OAO files?
Since the OAO format is detailed on the Motion website, I'd always assumed it was for software authors to add read support.
Clearly write support has recently had terms and conditions applied.
@Julien. What is the situation for software reading OAO files?
Permission is hereby granted to anyone to read OAO.
I trust anyone can read what was my very specific offer for and to ESP-GPS (and its users) and understand what my concerns were.
Thank you for the prompt Github change rp6conrad.
Select to expand quotedecrepit said..
And of course I'd like a WaveWands logo. (Can anybody do the Lady of the Lake's arm, catching Excalibur before it hits the water.)
This is not a nice picture to create a logo (sorry). Especially if it will be only 48x48 pixels. See example below.
The code can be easily added and generated at:javl.github.io/image2cpp/
Few steps to take:
1. Select the image
2. Image Settings:Canvas size = 48x48,Background color=white,Invert image colors = check,Scaling = stretch to fill canvas,Flip = horizontal.
3. Fiddle around with theBrightness / alpha threshold until thePreviewlooks OK
4.Code output format = Arduino code
5.Draw mode: = Horizontal - 1 bit per pixel
6. Then generate the code
It will look like:
// 'WaveWands_logo', 48x48px
const unsigned char WaveWands_logo [] PROGMEM = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff,
0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff,
0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xe0, 0x3f, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf8, 0xfb, 0xff, 0xff, 0xff, 0xff,
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xf0, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf0, 0x61, 0xff, 0xf7, 0xf0, 0x01, 0x00, 0x00,
0x00, 0xff, 0xe0, 0x00, 0x01, 0x00, 0x00, 0x1f, 0xe0, 0x00, 0xe0, 0x3e, 0x40, 0x01, 0xff, 0xf0,
0x0f, 0x81, 0x6b, 0xe0, 0xff, 0xff, 0xff, 0xb0, 0x7f, 0xff, 0xff, 0xff, 0xef, 0xf0, 0x01, 0xff
};
Now change the 1st line into (adding the size 304):
const unsigned char WaveWands_logo [304] PROGMEM = {
The logo code should be added to the file with the other bitmaps
github.com/RP6conrad/ESP-GPS-Logger/blob/master/Fonts/BitmapSurfbuddies.h
Then it should be assigned to a number matching the config file in the file
github.com/RP6conrad/ESP-GPS-Logger/blob/master/E_paper.cpp
logo_choice[0] are for the boards
logo_choice[1] are for sails
At the moment we have 9 positions mapped to these existing bitmaps. Not sure if we can use double digits for the logo choices, since I would not know the difference between 1 11 and 11 1
In the declaration it is set to integer:
extern int logo_choice[10]
github.com/RP6conrad/ESP-GPS-Logger/blob/master/SD_card.h
There is some code to deal with double digits:
if(Logo_choice > 99) {
logo_choice[0]=Logo_choice;
}
So this will allow to select a different board logo, but with default sail logo? Jan would know (I need to try ;) )
But as indicated, it's best to have simple logos that are well recognized, even in 48x48 mono. Do you have a better logo for WaveWands?
I have explored some code that could read the jpg or bitmap and convert it during the sdcard read to an epd bitmap. That would allow people to use any logo by storing the logo on their sdcard. That will make it easier to customize. However it is not very high on my agenda. Adding an additional logo is not much work, if we can select beyond 9...
Select to expand quoteJulienLe said..
Permission is hereby granted to anyone to read OAO.
Largely irrelevant. You knew about the use of .oao for the ESP logger for quite a while and never voiced objections, before you suddenly got all p*ssed and demanded all kinds of conditions.
Select to expand quoteFreezer said..decrepit said..
And of course I'd like a WaveWands logo. (Can anybody do the Lady of the Lake's arm, catching Excalibur before it hits the water.)
This is not a nice picture to create a logo (sorry). Especially if it will be only 48x48 pixels. See example below.
The code can be easily added and generated at:javl.github.io/image2cpp/
Few steps to take:
1. Select the image
2. Image Settings:Canvas size = 48x48,Background color=white,Invert image colors = check,Scaling = stretch to fill canvas,Flip = horizontal.
3. Fiddle around with theBrightness / alpha threshold until thePreviewlooks OK
4.Code output format = Arduino code
5.Draw mode: = Horizontal - 1 bit per pixel
6. Then generate the code
It will look like:
// 'WaveWands_logo', 48x48px
const unsigned char WaveWands_logo [] PROGMEM = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff,
0xfe, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff,
0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xe0, 0x3f, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfc, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f,
0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf8, 0xfb, 0xff, 0xff, 0xff, 0xff,
0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf8, 0xff, 0xff, 0xff, 0xff, 0xff, 0xf8, 0x7f, 0xff, 0xff,
0xff, 0xff, 0xf0, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xf0, 0x61, 0xff, 0xf7, 0xf0, 0x01, 0x00, 0x00,
0x00, 0xff, 0xe0, 0x00, 0x01, 0x00, 0x00, 0x1f, 0xe0, 0x00, 0xe0, 0x3e, 0x40, 0x01, 0xff, 0xf0,
0x0f, 0x81, 0x6b, 0xe0, 0xff, 0xff, 0xff, 0xb0, 0x7f, 0xff, 0xff, 0xff, 0xef, 0xf0, 0x01, 0xff
};
Now change the 1st line into (adding the size 304):
const unsigned char WaveWands_logo [304] PROGMEM = {
The logo code should be added to the file with the other bitmaps
github.com/RP6conrad/ESP-GPS-Logger/blob/master/Fonts/BitmapSurfbuddies.h
Then it should be assigned to a number matching the config file in the file
github.com/RP6conrad/ESP-GPS-Logger/blob/master/E_paper.cpp
logo_choice[0] are for the boards
logo_choice[1] are for sails
At the moment we have 9 positions mapped to these existing bitmaps. Not sure if we can use double digits for the logo choices, since I would not know the difference between 1 11 and 11 1
In the declaration it is set to integer:
extern int logo_choice[10]
github.com/RP6conrad/ESP-GPS-Logger/blob/master/SD_card.h
There is some code to deal with double digits:
if(Logo_choice > 99) {
logo_choice[0]=Logo_choice;
}
So this will allow to select a different board logo, but with default sail logo? Jan would know (I need to try ;) )
But as indicated, it's best to have simple logos that are well recognized, even in 48x48 mono. Do you have a better logo for WaveWands?
I have explored some code that could read the jpg or bitmap and convert it during the sdcard read to an epd bitmap. That would allow people to use any logo by storing the logo on their sdcard. That will make it easier to customize. However it is not very high on my agenda. Adding an additional logo is not much work, if we can select beyond 9...
For double digits, one could use a single logo, but with more pixels : 'Schwechatervert - Austrian Beer - by tritondm', 79x132px
This one is hardcoded with logo_choice 100. It still fits the screen, but the info on right side of the screen "speed in km/h" is not visible anymore.
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
Select to expand quoteFreezer said..
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
Cool, I presume it is the Mateksys M10-5883?
www.mateksys.com/?portfolio=M10-5883
I guess it can't be anything else based on the photos. :D
Select to expand quoteK888 said..Freezer said..
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
Cool, I presume it is the Mateksys M10-5883?
www.mateksys.com/?portfolio=M10-5883
I guess it can't be anything else based on the photos. :D
Correct, it should be plug and pray ;)
Select to expand quoteFreezer said..
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
G'day Freezer, is that bn220 one of the knock off versions? I had one like that and it didn't end up receiving as many satellites as the branded version.
Select to expand quoteshannon19 said..Freezer said..
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
G'day Freezer, is that bn220 one of the knock off versions? I had one like that and it didn't end up receiving as many satellites as the branded version.
I hadn't even noticed, but I guess you're right. I did see it only supported 2 systems instead of 3. So I was already wondering why this was the case... Could be older firmware as well. Not sure.
Select to expand quoteFreezer said..shannon19 said..Freezer said..
I received my M10 yesterday. Will hook it up next week and see if it works and is better on accuracy and power compared to BN220 and BN280.
G'day Freezer, is that bn220 one of the knock off versions? I had one like that and it didn't end up receiving as many satellites as the branded version.
I hadn't even noticed, but I guess you're right. I did see it only supported 2 systems instead of 3. So I was already wondering why this was the case... Could be older firmware as well. Not sure.
Yeah I got caught out with that building my first couple. It's important to search for Beitian bn220 in the stores. Someone else on here picked it up and when I checked mine they where the same. I ordered another couple. I'll have to put these others to another use.
Select to expand quoteFreezer said.. This is not a nice picture to create a logo (sorry). Especially if it will be only 48x48 pixels. See example below.
Wow thanks Freezer, I didn't expect anybody to go to so much trouble!
This is just a resurfaced whim from about 25 years ago. I never did get Excalibur on any of my decals.
When we moved to Avalon, I decided to name my boards, "WaveWands, by Merlin of Avalon", Excalibur seemed the natural symbol.
But very quickly that idea got laughed off the beach as being much too pretentious . So from then on it was just WaveWands, and Excalibur became too much trouble to implement.
You can't copyright a file format even if you came up with it.
You can copyright material that describes the format (eg protocol document, or source code). That doesn't stop anyone from *implementing* the format if you've published it. Generating the data contained in that format is something else- eg compression algorithms. These can be patented if they are novel.
I'm not a lawyer but its common (?) knowledge in software industry. Google it 
Select to expand quoteslowboat said..
You can't copyright a file format even if you came up with it.
You can copyright material that describes the format (eg protocol document, or source code). That doesn't stop anyone from *implementing* the format if you've published it. Generating the data contained in that format is something else- eg compression algorithms. These can be patented if they are novel.
I'm not a lawyer but its common (?) knowledge in software industry. Google it
That's all true. However, so far as I understand, Julien's primary concern relates to the lack of distinction between OAO files originating from the Motion and ESP.
The two devices already generate subtly different logs (e.g. HDOP vs PDOP, different metrics) and there is no sure-fire way to distinguish between OAO files from the Motion or ESP. Julian therefore proposed a way to declare "third party" in the format.
The majority of Julien's requests were directly related to the addition of a "third party" field so that it is clear to downstream software where the file originated.
Requests not to modify the file format are common sense to any developer, simply mitigating the risk of future compatibility issues. There is certainly a risk if any future changes occur without a "third party" indicator, potentially causing pain for everyone - Motion and ESP users.
The above points are purely technical in nature and make a lot of sense. Subsequent to-ing and fro-ing hasn't addressed the underlying technical concerns. Focus on "efficiency tricks" and such like have been something of a distraction from the compatibility concerns.
There were also a couple of requests which related to stating the origins of the format which (to be fair) is understable given the time and effort spent on the Motions as a whole.
ESP has now dropped OAO and with luck the open format initiative will provide a way forward in the future.
Had my second sail yesterday, in cleaned prescription glasses, with our boom mounted units.
I was concentrating on alphas, on smooth water, it was fine I could read the deviation display Ok, but once I hit the small chop, it became almost impossible to read.
To make this function useful for me, I'd need the deviation numbers to be much bigger.
Is it possible for the alpha function to take over the whole screen?
It's only for the first 250m after a gybe, so shouldn't affect the other functions too much.
I know some others aren't having this problem, is it because I'm light and bounce around more?
Or just that I'm ancient and my eyes can't follow a moving screen very well?
Anyway if somebody has a solution I'd be very thankful!
