Navigation
New forum topics
Syndicate
Holux M-1000C problems
Hi,
I am using the autoupdate development version of bt747 (great software, thanks!) with my recently bought Holux M-1000C AXN_1.0-B_1.3_C01 (01029-00A)
I have the following problems:
(1) When downloading the binary log, Altitude and Speed get misreported. It seems that Altitude is reported as Speed (the values here make sense), not sure what happens to the real Speed (the table shows fractions in the range 1.234E-41 - 1.234E-43),
(2) After downloading the log a few times, the device became corrupted, i.e. bt747 was not able to download the log any more. Clearing the log with the vendor supplied software fixed the problem. I am unable to reproduce this issue.
(3) Erase log does not always work.
Any ideas?
Regards,
rt
- Login to post comments
Hm, PHLX - I think Qstarz
Hm, PHLX - I think Qstarz BT-1000X, iBLUE 747+ will have those aswell, since all these are clones..
Holux vs. Qstarz
In the beginning the devices were perfect clones, but now they are not so perfect clones anymore.
The Holux-M241 already had some differences - it had to because it had a display. The components used were mostly the same, but the board was different of course.
Holux clearly continued to change the device SW.
Stable vs development
Holux changed the log format "slightly" in the Holux M1000C.
In principle in the latest 1.68.28 version the 'issue' with the speed and height conversion should be solved, but you need set the device type correctly (HOLUX GR-245) for conversion. Same for 2.X. If you still find problems, I'll check it out and fix as needed.
Further a full download is performed if the device was in overwrite mode upon erase (or if it already started overwriting data). This is to secure the data.
Regarding that point I've made some changes to the 2.X version to make the download 'smarter' - I am not sure this is in the 'released' build yet.
QQ
mdeweerd, i'm referring to MTK II devices, which seem to be clones - well, at least their "official" software seems to be exactly the same, only with different title.. i'll check the latest versions. Do you have any faster contact, or should I just report everything here?
QQ
I've just tried 2.x, and indeed it downloads something and converts something now! Now I just gotta check if it's correct.. :)
I have a 'faster'/other
I have a 'faster'/other contact which is in the about function of the application - or through the contact form of this site.
The logger may have the same SW, the same Firmware for the GPS module itself, and different embedded SW. For instance, the model type is determined by the latter and is different for a Holux M1000C than for an iBlue 747A+.
I have an iBlue 747A+ which decodes just fine using the 'default' decoder, while I have some Holux M1000C logs sent by 'rt' that are different. The Holux M1000C is similar to the Holux M241 logs, but the speed is no longer expressed in km/h and in floating point, but in m/s and as an integer. The number of bytes allocated for height and speed fields is different than for the 747's.
QQ
Hm, oh dear, why would they do that.
Anyway, downloading from BT747 desktop seems to work fine now, woohoo! Still have to debug what "resets" capture time setting to default 5 seconds though (I know for a fact that ezTour resets what is capture and deletes agps data [btw, can this Holux use agps..?])
I've tried J2ME app, and noticed one problem straight away - the "protocol" setting isn't remembered. And dont know if it's because of that, but downloading does not work..
.
It would be easier on me if you get an account on this site ;-).
The application coming with the device (at least in case of the iBlue 747A+) seems to reset the log conditions.
Download through J2ME should not be conditionned by the protocol setting.
It is likely that the problem is the 'output directory'.
The protocol setting is beta (this is really the communication protocol) and not used/remembered. It is not important for the download. The device type used for conversion is set in the Convert Menu (default = Default Device).
I believe that rt told me in private that AGPS works. Just try it. If the upload button is active, it should work.
As for the reason: they can put more position in the same memory footprint - regarding the units: possibly the precision is better [more significant bits when compared to floating point format]).
Hello, sorry, I've signed up
Hello,
sorry, I've signed up :)
Anyway, I've did some more testing yesterday on the whole "resetting" thing, because it really annoyed me. Here is what I've figured out:
* manufacturer's software resets following data: deletes AGPS data, resets what types of data is logged, resets logging period. Does not reset fix frequency, but seems to sometimes fail to work when set at 5hz
* manufacturer's software seems to be the only one that knows how to permanently set logging period. If i set it through bt747 or MtkDLut, it is reset to whatever has been set by original software on next power cycle (how long did it take to figure this out!). However, it is possible to set what is logged and fix frequency and it stays
* THIS IS IMPORTANT: Uploading AGPS data seems to reset EVERYTHING to some default values: 1hz, 5s period, time/lat/long/alt/speed! So even though it apparently allows to upload AGPS data (though I dont know how to check if it makes use of it), it is unusable since it resets everything else..
* It will not accept decimals places in logging period - well, perhaps it would, but original software does not allow to enter one, and, as I've said, setting it with custom software does not make it stick
* otherwise, log downloading seems to work perfectly with latest version of bt747, albeit "smart downloading" (and I think it should download only appended data, correct?) seems to sometimes insist on redownloading everything
I still need to recheck j2me version download issue - didn't have time yet.
hope this helps anyone :)
Thanks ;-)
To be precise: did you or did you not set BT747 to the new protocol (you should not for the moment) - the device setting is needed for conversion (I repeat myself, but I want to be sure).
If the 'official SW' can change the settings, BT747 can be made to do so too. 'rt' is working on adapting BT747 so your tests are usefull.
The memory will be fully downloaded if the logger is in overwrite mode. If your memory is partially empty, it should not.
Can you activate the 'raw debug mode' before connect, then connect and do the download? After that, disconnect, and send me the gpsRawDebug.txt file (in destination directory) plus the downloaded log. My mail is in the about function of the application.
That way I can check why BT747 decides to download everything and possibly find another 'smart trick' (or make a correction).
I think I might have been too
I think I might have been too quick to judge the "smart" download mechanism, at the moment it seems to function corectly.
Yes, I set protocol in desktop version to H-M1000C, should I change it?
I found one more bug in conversion routines. CSV conversion seems to work correct, producing line:
INDEX,DATE,TIME,LATITUDE,N/S,LONGITUDE,E/W,HEIGHT(m),SPEED(km/h),HDOP,NSAT (USED/VIEW),
2259,2009/07/01,10:12:53.000,54.913868,N,23.946291,E,97.115,47.304,0.98,8(10),
but GPX conversion writes speed incorrectly:
<trkpt lat="54.91386795" lon="23.94629097" >
<ele>68.826</ele>
<time>2009-07-01T10:12:53.000Z</time>
<speed>13.1400</speed>
<name>trkpt-2009-07-01T10:12:53.000Z</name>
<cmt><![CDATA[<table width=400><tr><td>TIME:</td><td>01-JUL-09 10:12:53</td></tr><tr><td>RCR:</td><td>T <b>(TimeStamp)</b></td></tr><tr><td>LATITUDE:</td><td>54.913868 N</td></tr><tr><td>LONGITUDE:</td><td>23.946291 E</td></tr><tr><td>HEIGHT:</td><td>68.826 m</td></tr><tr><td>SPEED:</td><td>47.304 km/h</td></tr><tr><td>HDOP:</td><td>0.98</td></tr></table>]]></cmt>
<sym>TimeStamp</sym>
<type>T</type>
<sat>8</sat>
<hdop>0.98</hdop>
</trkpt>
notice, how it writes speed correctly in comments area, but not in the speed tag..
Speed
The speed in the 'speed' tag in gpx is expressed in m/s so 13.14 m/s * 3600 s/h * 1 km/1000m = 47,304 km/h.
Good for the smart download then ;-).
means RouteConverter is
means RouteConverter is misinterpreting it then.
How would you suggest we debug "time period does not stick" issue?
Time period does not stick...
I believe 'rt' was on it, I need to go through my email.
If not, a serial communication tracer has to tell us what the 'official tool' does and then we can 'copy' this to BT747.
This is the idea of the M1000C specific protocol, but this is still under debug and incomplete.
Do you have experience with
Do you have experience with tracer? I could log and send to you.
Btw, ezTour somehow knows when a new track is started, and can split whole log by tracks in a nice way. BT747 always converts it as a single track. Perhaps it's possible to detect a new track start in binary log?
Furthermore, the "new track
Furthermore, the "new track after .." setting doesnt seem to work for me, converted GPX always contains only one track..
One more note: the setting
One more note: the setting where you specify what conversion type to use is not remembered :)
Btw, ezTour somehow knows
Btw, ezTour somehow knows when a new track is started, and can split whole log by tracks in a nice way.
Start ezTour. Main Menu -> Tools -> Options -> Track -> Separate tracks when waypoint time difference is more than [] minutes.
Can you confirm it gets any smarter than that?
For the record, I am using ezTour v1.01 (2009-03-24).
Good catch. I'll check it
Good catch. I'll check it tomorrow. Yep, same version here, too bad Holux is slow on updates.
Can you confirm that bt747's split setting doesnt work? Plus, would be nice to have both time and distance setting for splitting tracks (AND ability to define OR/AND relation for them)
Not remembering the
Not remembering the conversion type is on purpose: the first conversion usually is towards the GUI.
Most conversion types are represented in the buttons anyway.
'New track afte'r does not always create a new file - that depends on another setting. I am surprised that you do not get small tracks. Did you check when you open your gpx file in Google Earth.
It can be that the tools splits tracks based on an on/off cycle of the device - I can add that and I plan on doing so.
Sorry, I poorly explained the
Sorry, I poorly explained the setting - I meant the "device" setting, where you set for example Holux GR-245.
Yes, I know new track isn't supposed to create a new file, but it doesnt create new tracks in same file either. To be frank, I did not check it in google earth, since I don't have that installed, but I checked resulting GPX file, and it only contains a single branch with all the 's placed under it. I think it should contain (or is it ?) for each new track? Also, what do you think about time/distance based splitting?
3rd point - that's initially how I thought it does. But rt's point made me doubt, so I'll have to double check it. If it's possible to add splitting by power cycle thought - it would be great (and very logical too :) )
Time & distance logging criteria
* manufacturer's software seems to be the only one that knows how to permanently set logging period. If i set it through bt747 or MtkDLut, it is reset to whatever has been set by original software on next power cycle (how long did it take to figure this out!). However, it is possible to set what is logged and fix frequency and it stays
I have created a fix for this issue and checked in to my branch of bt747 (r1472).
This needs some explaining. In short: M-1000C *does* accept the "old" PMTK-command based setting of logging criteria (time, speed, distance). However, for some reason, Holux decided to introduce a new command for performing this task in their new PHLX command set. The new command is "PHLX834" and it does two things:
While the first thing is pretty harmless (you could simply ignore the command and use the old PMTK commands to achieve the desired effect), the second thing causes more trouble: since it restores the settings of last PHLX834 every time you boot the device (without actually reissuing the command by e.g. running ezTour), it is impossible to persist criteria set by the old PMTK command -- the new command "overwrites" them.
In order to make the behavior predictable to the user, I made time and distance mutually exclusive in the J2SE (desktop) app. I also implemented the actual PHLX834 functionality so that the settings are now persisted after GPS power cycle.
As you see, this is a kind of a mixed blessing. The good news is that logging by speed is unaffected by this.
This fix could really use some good testing, especially whether these criteria really work as expected and whether it is still compatible with ezTour (while it's not a priority, I don't want to break ezTour compatibility without a good reason). If you (or anyone else) want to help testing, I'd be most grateful.
The way GPS Photo Tagger splits (= ezTour?)
Hi
I checked out GPS Photo Tagger which should be the same or similar tool.
Track splitting is done based on time separation (as in BT747 which was the first tool to do so).
I added track splitting based on the logger 'on/off' entry. It seems that this entry exists in many cases - even when not doing 'on/off' - I do not exactly understand the entry reason finally - it looks like it is added when the fix is lost too.
Anyway, a build of this new 2.X version is ongoing. It adds an option in the output settings tab.
Neutralizing PHLX834
the second thing causes more trouble: since it restores the settings of last PHLX834 every time you boot the device (without actually reissuing the command by e.g. running ezTour), it is impossible to persist criteria set by the old PMTK command -- the new command "overwrites" them.
One thing that comes to my mind here is that it should (theoretically) be relatively easy to to go over the firmware of M-1000C and neutralize the effects of this command ("the restore settings on boot" part should be sufficient). The traditional way of finding the offending part of code and replacing the opcodes with NOPs should do the trick. The cool thing is that in this case the compatibility with ezTour would not be completely broken.
Normally, I wouldn't be proposing it but since Holux is unlikely to ever issue a firmware upgrade for this device, this might actually be not such a bad idea.
So much for theory; in practice, I don't think I have the necessary experience to do it. Anyone?
Is MTK II firmware publically
Is MTK II firmware publically available, unencrypted and compatible among all the different vendors?
p.s. huge thanks for all the other updates! Unfortunately, time ran out for me, I'm leaving for my two week trip. On the other hand, this will be great opportunity to test it all :)
3 firmwares ...
IMHO, there are 3 firmwares in a logger:
- MTKII Chip(set) firmware - Handles the GPS - position calculation, ...;
- "Vendor FW" -> handles the logging code, communication with external worls;
- Bluetooth firmware - probably not very accessible.
So when we talk about FW, we mean the "Vendor FW".
What we are interested in is the Vendor FW and for some devices this is surely compatible, but for others not. For instance, I am pretty sure that the iBlue 747 FW is not compatible with Holux M241 FW. The M241 needs to handle the screen, where ass the 747 does not have one.
Is MTK II firmware publically
Is MTK II firmware publically available, unencrypted and compatible among all the different vendors?
Mario has given a nice overview of how it works in practice.
The availability of firmware for Holux devices differs. For some devices you simply go to Holux website and download it. For some you need to search a bit more, sometimes the resellers have it, sometimes Holux sends new versions to individual users. For some other devices it may be that the firmware is not officially available. I believe Mario said that it is possible to download the firmware from the device.
I do not know what the status is for M-1000C.
p.s. huge thanks for all the other updates! Unfortunately, time ran out for me, I'm leaving for my two week trip. On the other hand, this will be great opportunity to test it all :)
Just bear in mind that logging criteria setting is not integrated in the main branch yet so you need to use ezTour if you want to change it.
Enjoy your trip! :)
I have set it all already,
I have set it all already, 2s, 5hz, tried it a bit with local trips, seems to work fine :)
The only thing that I still can't get to do is to get bt747 split by time AND place tracks in single GPX file. When setting one gpx per track, it splits them fine, if all in one, then only one track is made in gpx. And it would be amazing if split by time OR/AND distance option would be added.. :)
thanks everyone, you guys are great!
Apparently the split did not
Apparently the split did not happen in the GPX file while I was convinced that it was.
I've now fixed that in 1478.
With the changes that I made, it should be 'easy' to add distance filtering so that will be coming up.
mrQQ Here is the deal: you
mrQQ
Here is the deal: you asked for it, you test it! ;-)
Track splitting based on distance is added. I am not sure about the accuracy of the distance calculation - at least the order of magnitude seems ok. Distance is taken as earth distance - height is not taken into account.
Small values for distance separation may result in many tracks, so I recommend a minimum setting of 2000 meters.
All in BT747_2.X.1481 .