yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi vvixx,

on my device mapnik works. Do you use the latest gcc version (4.8 or 4.9beta4)? Does your internet connection work? Sometimes a reset of the device helps.

There must be already a valid OSM tile structure in the choosen map files directory, because gcc detects the type of the map (jpg or osm) from the available data. (The next version assumes osm if the directory is empty.)

Klaus

---------- Post added at 01:30 AM ---------- Previous post was at 12:40 AM ----------

hi low.flying.pigs,

thanks for your thorough testing and using gcc. I will consider your suggestions in the further development, but system related functions are difficult.

Could you please send me some corrupted gcc files for investigation what is going wrong. I don't like to store 2 files and if the first file is corrupt it is likely that the second is also corrupt.

Your observations:

S/Snr: is usually stable. Could you please "log raw nmea" (context menue on GPS field) and send me the \tmp.txt

Speed lag: if Average=1 this is the lag of your GPS receiver.

Klaus
[Touch Diamond, MDA Compact IV General] CLAUDIOGPS:
some requests

Hallo, is the first time that I meet this thread and I say that this software is very very very good. Maybe I lost some suggestions in previous posts, but I found this program two days ago. I have a problem to copy a large map (for example 500 mb) on a sd card: it takes a long time, because it is formed by a large number of files (same problem to delete it). Mobile atlas creator offers a variety of formats in which maps are formed by few large file (for example Oruxmaps sqlite, that I use for the program oruxmap in Android ). Is possible to use any of these formats?

Another request: is possible to have an option to have the rotation of the map in the direction of travel?

Thank you and again congratulations for the software.

Claudio.
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi Claudio,

you are not the first with these requests. The single file map is also my big wish, but I can not realize all at a time. I want to use RunGPS format.

The map rotation is somwhat difficult and CPU intensive since this is no vector graphic.

Klaus
[Touch Diamond, MDA Compact IV General] CLAUDIOGPS:
Hallo Blaustein, is possible, in future, add at the contest menu of map display an item to change map? In this case would be possible to change map display without pass throug the option screen screen.

Regards.

Claudio.
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi Claudio,

No. Context menu is already very long in map screen and you need one long and one short click to select an item. With one long and two short click you can reach the item in options page (and these clicks are more finger-friendly than context menu).

Klaus
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

Thank you for your reply.

Regarding the suggestions for new features, the thing I miss most from my old traditional cycle computer is the Odometer. It would be great to have that functionality. GCC collecting data as it does, could show cumulative statistics to date, but just total milage would be a great addition at some point in the future.

Regarding corrupted .gcc files, unfortunately, I have not been keeping them lately, but I have found one from last year.

It was easy to search for as I recall the ride, the date and it happening, and being somewhat annoyed as I wanted a log of that ride.

I don't recall exactly what caused it to go wrong that time.

When reloaded the corruption is apparent, it shows the trip as being 4041.1 miles long, at an average speed of 2167 miles per hour.

Regarding duplicating the .gcc file to recover from a scenario like the above, having thought about it a little further, perhaps a better idea would be whilst the main .gcc file is logging, create a backup snapshot of it periodically. Then create another after the same period has elapsed again, but with a different file name. Then continue, overwriting the oldest backup first.

At least one backup should then survive intact, with minimal lost unrecorded ride data, if the other backup and main file are corrupt from being written when disaster struck. Backups could be discarded automatically if the main file is accepted and completed normally by pressing the stop button without disaster having struck.

Regarding logging raw nmea, I have done a quick stationary log. Can't ride at the moment due to ice and snow.

The tmp.txt and corrupt .gcc are attached.

I note the number of nmea sentences in the raw nmea tmp.txt from the GPS receiver vary from one second to the next. I don't know if that is normal, or whether that may be why the S/Snr is not constant if the receiver does not send this information each second.

The GPS receiver is model BT74R from 2005, it does not show a manufacturer.

As you state the speed lag problem is due to the receiver, and I want to resolve this, then a new receiver may give better performance without lag, and provide constant S/Snr.

Can you offer any guidance or suggestions which receivers offer the best performance.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] CLAUDIOGPS:
map change

Hallo Blaustein, oh yes, I did'nt know that with a long touch in the left bottom come the screen with option icon. I have to reed better the instruction sheet.

Regards.

Claudio.
[Touch Diamond, MDA Compact IV General] Blaustein:
new beta version 4.9beta5

Hello low.flying.pigs,

your GPS receiver sends the $GPGSV sentence only every 2 seconds. This is why SNR blinks. But this is only a beauty fault and does not matter any further. BTW your receiver seems to have a SW bug: the SNR value of the 4th sattelite is missing (last in the first sentence).

I think your corrupted gcc file can be repaired. I have attached it. Please check, if possible, if all data until the crash is present and correct. Please collect and send me more corrupted files. I want to make a repair function.

I have attached a new beta release 4.9beta5.

New features (above beta4):

- Tracks are no longer restricted to 18 hours

- Restore last session (active tracks). Done automatically after crash.

- Odometer. You can set your initial ODO in gccState.txt (first line [m]). Don't change anything else!.

Klaus
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

Thank you for your reply, and the new 4.9 beta 5 with Odometer function. Excellent work!

I have just downloaded the first copy, installed it and edited the gccState.txt file having converted miles to meters, and look forward to testing the feature.

(if it helps anyone: 1 mile = 1609.344 meters, so calculate 'your number of miles' multiplied by 1609.344 to convert)

Extending the feature to include accumulated totals for altitude, speed average, and speed maximum data would make the feature comprehensive, as would configuration from within the options section with automatic handling of entry in miles if that has been selected in the Main Screen section.

Thank you for confirming the problem with the GPS receiver. I am going to replace the GPS receiver for one that sends data every second real time without delay, so that the speed displayed is more responsive. Finding such a device is somewhat difficult. If anyone has any suggestions, it would be appreciated.

Thank you for your efforts in trying to repair the corrupted file. From memory, I think it is at least mostly complete, if not fully complete, up to the point where failure occurred. If the proposed repair function is built in to GCC, and whatever has caused the failure, such as a flat battery, can be resolved whilst out on a ride, it will be a good solution.

That is unless the file has been corrupted beyond repair either entirely or in part, by the failure. In that case the automatic dual periodical backup snapshot solution I described earlier would always provide a guaranteed working file that is as complete as possible. It would seem easier to code the backup of existing working files, than a repair process for already corrupt files. It might also be more sensible especially where the corrupt file may be of unknown integrity with unknown remaining salvageable content.

I will send any other existing corrupted files I haven't deleted when I locate them, as well as any new ones that occur, by direct email, as requested.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] CLAUDIOGPS:
maps

Hallo Blaustein, for when you will have time to put hands on use of other maps format, I report to you a program very valuable, alternative to MOBAC: his name is "global map downloader", made ​​years ago to provide maps to a navigation software for cracked psp named "mapthis." This software, "GMDL", allows you to download maps from various sources (google, microsoft, etc.), and has numerous facilities such as variable compression, immediate control of the map, etc.. The maps constructed in a first time were type OSMTracker, then allowed also a format made by 5 big files. The link of GMDL is "in7ane.com", other news in "deniska.dcemu.co.uk." (I cannot put www because is impossible for me. -less then 8 posts-)

I hope the report will be useful.

Regards.

Claudio.
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello low.flying.pigs,

I have changed the gps driver, so that it trusts the old GPGSV data for a maximum of 10s if there are no new GPGSV data.

Concerning the backup files, I don't want to implement such a resource eating function which only produces many useless files. I never heared of big problems with corrupted files. And I am convinced your file is also not corrupt. I think GCC logged absolut correct the data from your GPS receiver. 10 points before the end there was a gap of 6 minutes and the last 10 points were 1000s of km away and growing even farter. I think your problems will be gone with a new GPS receiver. I can give no advice for a good device, I use the internal one of my smartphone.

Klaus

---------- Post added at 07:21 PM ---------- Previous post was at 07:19 PM ----------

Hi Claudio,

the other map format is quite a big peace of work. I can not promise to have it done in the near future.

Klaus
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello low.flying.pigs,

you are right, you only need to remove the erroneous data points from the end of .gcc file. The data format is not that complicated. There is a header of 26 bytes and after that only records each of 10 bytes (except for waypoints, which have additional bytes for the name). You must remove whole records (multiple of 10 bytes). I attach the gcc format description.

In your last file there are only 2 erroneous points, but due to the 1000s of km away, there are many reference shift records inserted.

Concerning you issue with logging other than 1s. There are 2 different kinds of values. First the "current" values which are independant of any track, like current speed or current altitude. Second there are values dependant of a track, like distance, trip time or altitude gain. These values are calculated in the logg task and therefore are not calculated if the point is not logged. Changing this is very complicated, because of the complexity of the code at this point, due to the numerous options and modes. It's very dangerous to put any bugs in.

In addition it would have the consequence that the track data would be not the same if you reload the track from file. If you move not the shortest straight line from one logged point to the next logged point and have some (not logged) points inbetween, the distance would be greater than the straight line. If you reload the track from file, the distance is calculated as the straight distance between the logged points. In my opinion the current solution is the lesser evil.

Klaus
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

Thank you for providing the .gcc format information. I will have another attempt at a Do It Yourself repair in due course.

Thank you also for the detailed explanation regarding my observation of the log interval affecting the update frequency of the time h:m:s on the main screen. It is apparent now why it works in the way it does, and why it may not be straightforward to address this behaviour.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] giasone73:
Hello Blaustein / Klaus,

finally I tried your last beta version. It work fine but I have a problem. Usually I use gcc on a palm with external gps antenna and sometime I put it in my jacket pocket. If happen that I go far from my bike, where i fix the palm, it lost the Bluetooth connection and the gcc crash. The only way to solve the crash is to reset the palm.

Can you solve this problem and suspend the logging if lost gsp signal or bluetooth connection?

thank you

Alfredo
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello Alfredo,

I can't reproduce this because I have no Bluetooth GPS device. But I am convinced that GCC cannot solve this problem. If there are comming no data from serial port, there is a timeout of 300ms and then simply displays the GPS status message "no data from GPS".

Can you test this Bluetooth disconnection with other SW?

Klaus
[Touch Diamond, MDA Compact IV General] giasone73:
Hi Klaus,

I'll try this evening but are you sure that the timeout is 300ms? or 300 s because I wait very long time before reset but sure not for 5 minutes.

Alfredo
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi Alfredo,

I suppose you have a problem with your Bluetooth driver or virtual COM port driver, which crashes the whole device. Perhaps you can find an updated driver for your device.

Can you open the COM port with an other application, to see if it crashes too?

Also you could try in GCC not to use "Read GPS data directly".

Klaus
[Touch Diamond, MDA Compact IV General] fabrylama:
Hi Klaus,

I recently found a way of logging the heart rate using my htc diamond and a very simple hardware hack (very cheap [1€], not invasive and easy to make), turning my old phone in a "complete" bike computer.

I want to ask you if you are interested in adding this feature in your app, for now I'll start explaining how it works, if you are interested let me know and I'll go into the details.

For the hardware hack: I just created a "wireless" antenna, connecting a small inductor (coil) instead of the microphone in the diamond headset.

When I want to log the HR, I place the antenna near the polar belt (or any 5khz HR belt, the kind that works on every gym machine) and I start recording the audio.

The resulting mp3 (i can give you many sample) is very simple to decode, because for every heart beat there is a short (0.1s) and powerful "beep" (at 5khz) (or a couple of beep in the more recent coded polar belts), from there it's just a matter of synchronizing the HR with the GPX points (i wrote a small sw in LabView) and it's done!

I'm very happy with this arrangement, but it's a little tricky to operate, mainly because the mp3 recorder I use (Vito voice recorder) stops recording if the power button is pressed, so the phone must stay active (but I can turn off the screen), but sometimes all it takes is a bump on the road... and the recording is off.

Unfortunatly I have very little "real" programming experience, so I have no idea how to, and how difficult would be to modify your app in order to detect/decode in real time the HR... :p
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi Fabrizio,

this is very interesting. I already started an approach to add an bluetooth heart rate belt, in cooperation with another user, but stopped right at the beginning because the user couldn't operate the belt beside his bluetooth gps receiver.

Your "hardware hack" sounds like it could work with every cheap belt. I will check how I could detect the signal. It will not be so easy to access the microphone and decode the signals in real time.... but it's interesting.

Regards

Klaus
[Touch Diamond, MDA Compact IV General] fabrylama:
Hi Klaus,

I'm really glad you're interested!

As soon as you manage to access the mic let me know, so I'll tell you my method for decoding the signal and, more importantly, for filtering the HR results

Keep in mind that a 2kHz sampling rate would be enough to correctly detect the signal, because every heart beat is an 5-7 milliseconds burstlike this:

in a sequence like this:

with a 2kHz sampling rate, there would be 10-15 samples for every burst, more than enough to detect it's peak.

Ps. For future reference:

The polar coded transmitter uses a different pattern, it generates 3 close burst for every beat: 5ms for every burst, the first burst is the detected beat, the second burst is emitted after ~20 to ~200ms (this time is infact the "code", every belt is different) and after 20ms the third burst.

I simply handle the two belt in the same way, discarding every burst that is too close (<250ms) to the "last" one.

Fabrizio
[Touch Diamond, MDA Compact IV General] Blaustein:
Hi Fabrizio,

I am currently working on accessing the microphone on my desktop PC (it's much easier to debug and not a big difference) in a manner suitable for this purpose. It's nearly ready to use, I only have to implement some cyclic buffers to deal with an endless stream of data.

With 2kHz sampling rate you are undersampling the 5kHz beep, but it should work anyway (unless the beep is an exact multiple of the sampling) when you only detect the envelope of the signal.

BTW you could put a capacitor in parallel to your coil to form a resonant circuit at 5 kHz. This could make it more robust against unwanted signals. Or you could implement a little amplifier and filter similar to: http://home.swipnet.se/~w-10522/tomas/receiver/receiver.htm (the first 2 or 3 OPs). This could extend the range to 1m.

Klaus
[Touch Diamond, MDA Compact IV General] fabrylama:
Hi Klaus,

I already tried with the resonant circuit, with a 5mH coil in series with a 0.1uF capacitor (5khz resonance and high Q factor): the results were very good, but the coil il really big (2x1x1cm), and the result is very orientation-dependent (the signal is good only if the coil is parallel to the belt).

With a smaller coil (1mH low resistance, 1uF capacitor) the q factor is smaller but still good and still very orientation dependent.

This configuration is good if you keep the phone fixed on the handlebar, this way it would be easy to build a coil directly onto the microphone connector, and the orientation would be fixed, but since I keep the phone in the jackets's back pocket, I cant control the orientation, so it's just easyer to use a very small coil (something like 0.5mH) with a 30cm wire, directly tied to the belt. Since the coil is so close to the transmitter, the signal is always strong and, so far, I have seen no noise at all.

The amplifier you suggested looks interesting, I will try it as soon as I find the time!

For the undersampling:

I suggested a low sample rate because I thought it would be easyer to handle, I don't think undersampling is a problem because we only need to detect the burst, we don't care if it's distorted (aliased) and with a 2khz sample rate we would have at least 10 sample for every burst, more than enough to detect it.

Maybe this is true only on my noise-free configuration, probably with the reciever 0.5 far from the belt it would be important to correctly sample the signal.

Right now I use a 2khz sampling rate for performance reason, with a 22khz sampling rate it took up to 2 minute on my pc to parse 1 hour of audio file.

Attached you can find audio sample of the 2 polar belts i own (coded and non coded).

As for the filtering: sometimes, when the belt moves (it happens often offroad), the belt skips a beat or transmits an extra burst, the result is a sudden decrease/increase of the calculated HR, to avoid this at first I simply put boundaries (40-210bpm) to the calculated HR and averaged the current value with the last 5.

This helped, but it wasn't enough, so now I make an average of the past 5 HR values and when the new HR is calculated, if this value is too far (more than 10 bpm) from the average it's simply discarded (the average isn't updated), this way the signal is very smooth, but if more than 5 consecutive HR are discarded then the average is resetted.

This way the HR tollerates well the occasional extra burst, but it's still very fast on following the physiologic HR increasing/decreasing.

I hope this is useful info.

Fabrizio

Ps. for the logging: I found contrasting info on how to insert HR data into the GPX file, in the end I decided to convert the gpx to the TCX (garmin) format that offer a native support for the HR. Tell me if you need info or a sample file.
[Touch Diamond, MDA Compact IV General] Oldie56:
Mobile Atlas Creator

The link to mobac given in the readme file is outdated. Could be moved to a sourceforge project. Sorry that i do not give the url here. Im not (yet) allowed to.
[Touch Diamond, MDA Compact IV General] Blaustein:
Oldie, thanks for the hint. Klaus
[Touch Diamond, MDA Compact IV General] fabrylama:
Hi Klaus,

any news? :p

Fabrizio
[Touch Diamond, MDA Compact IV General] Blaustein:
new beta version 4.9beta7

Hello Fabrizio,

here is a new beta version with heart rate support. In main display in the speed field you must enable heart rate support and display (you can also display signal strength). If you are logging you can display a graph to show heart rate over time or distance (click the graph button in graph display to switch from speed to heart rate display).

BTW: I had to use 16kHz sample rate because my sound card filters the 5kHz pulse away if the sample rate is beneath 10kHz. But it is ok since I only use buffers for 2 seconds.

new features in advance of 4.9beta5:

- Sattelite and Snr is no more blinking if $GPGSV is not sent every second (trusts for 10s)

- foreground an background color can be set in options - main

- file names of current track and t2f are now displayed in options (firs page)

- a warning is displayed if you try to continue a track which is more than 1km distant.

- live logging with crossingways and automatic map download is now asynchron (doesn't block application)

- all osm servers are defined in "osm_servers.txt" ("osm_server.txt" is no longer used)

- osm download server are stored for each map separately in corresponding map directory in server.txt

- edit T2F: add points click by click in map screen. Also remove and undo function.

- support for heart rate belt. You need a hardware to feed the heart pulses into the microphone input.

Klaus
[Touch Diamond, MDA Compact IV General] fabrylama:
Hi Klaus,

the first impression is really good: the HR is consistent with my polar reciever, as soon as the weather is good I'll try the logging!

Thank you very much!

Fabrizio

P.s. would it be possible to enable the logging also with the gps off? This way it could also be used for indoor training.