| Versions |
 |
|
| Author |
Topic  |
|
mdeweerd
798 Posts |
Posted - 26 oct. 2007 : 21:16:27
|
My iBlue 747 outputs the following NMEA string (the checksum is in error in the example as I changed the location for privacy):
$GPRMC,190633.500,A,4800.0000,N,00200.0000,E,0.31,123.10,261007,,,A*68
I can not explain the 'A' at the end of the string (just before the '*' initiating the checksum.* Documentation concerning GPRMC that I can find on the net shows the format like this (one of the references is http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf): $GPRMC,hhmmss.ss, A,llll.ll, a,yyyyy.yy, a,x.x, x.x ,ddmmyy,x.x,a*hh
where the last 'a' is supposed to be E or W . The last A coming from my iBlue 747 is an extra field!
Does anyone know if this extra field is ok? Is it the same for the other MTK devices?
UPDATED: found it myself finally (http://amplified.com.au/files/iGPS-EB-1_User_Manual_Amplified_Engineering.pdf) A= Autonomous ; D=DGPS mode.
|
Edited by - mdeweerd on 26 oct. 2007 21:28:09 |
 |
|
|
knights191
2 Posts |
Posted - 29 oct. 2007 : 18:59:41
|
Is there any way to turn Static Navigation off with an iBlue 747 (Konet BGL-32 | M-Core 1.94) I have read something about setting it at 2 hz and then the SN should be gone, but this does not seem to work.. I cannot find a good tool to set it,
When I run GPS View 1.1.0 I can connect bit within 1 sec I get an error like '7512615621 isnt a good floating number' Anybody can help ?
|
 |
|
|
gpspassion
93394 Posts |
Posted - 29 oct. 2007 : 19:04:48
|
At the risk of repeating myself, there is NO SUCH THING as "static navigation" on MTK receivers, this is a SiRF firmware setting. Prior to v1.92, MTK receivers had a PROBLEM with low speed tracking, it has now been fixed as can be seen in these comparisons for instance.
For your floating point problem change your regional settings to ENGLISH/US |
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
 |
|
|
knights191
2 Posts |
Posted - 29 oct. 2007 : 19:14:25
|
Thanks alot for clearing this up. Floating Point problem solved when switching to ENGLISH/US. just 2 questions;
When my MTK receiver is inside, The speed goes crazy from 30 km/h -> 110 km/h..this thing looked like static navigation... it seems it has trouble 'standing still' any suggestions for this ? Is it better to put it at 5hz then at 1hz ?
Thanks GPSPassion! |
Edited by - knights191 on 29 oct. 2007 19:22:06 |
 |
|
|
gpspassion
93394 Posts |
|
|
musky
USA
226 Posts |
Posted - 30 oct. 2007 : 13:50:00
|
GPSPassion: In regard to your statement that the MTK "PROBLEM" should not be called "static navigation"....
Back a half year ago, when I evaluated an MTK unit, I used the term "static navigation" <note the quotes> because at that time I assumed that the PROBLEM was somewhat if not totally intentional. How can a manufacturer have low speed behaviour problems like that and not be aware of it through testing!! It blows my mind! They never beta tested the unit by actually going outside and taking a little walk with it?! I could only assume that the PROBLEM was an algorithm similiar to static navigation, where they are trying to sense a fixed condition, and reporting zero speed and bearing (similiar to Sirf static navigation)
Since then, Semsons has stated publicly that it was a bug (?!?!?) and that new units have it fixed. Whatever... the skeptic in me still smells something funny here, but lets call it the "Low speed bug" |
 |
|
|
gpspassion
93394 Posts |
Posted - 30 oct. 2007 : 15:53:30
|
Yes and Qualcomm has the same problem on the MSM7200, I think it comes down to the difficulty, especially on high sensitivity chipsets working with noisy signals, to tune a GPS for both car and pedestrian use and up to now car use had been prioritized. Compared to MTK and Qualcomm, SiRF have the benefit of 5+ years of performance tuning under their belt! All I can say is that based on my testing of v1.94, pedestrian tracking si now on par with SiRFstarIII, see the link I gave above.
Anyway, firmware v2.0 spotted on the BT-Q1200, added to the firs message.
 |
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
 |
|
|
Luh
3 Posts |
Posted - 31 oct. 2007 : 15:23:49
|
Do I understand it correctly that there is no way of ugrading firmware on any MTK unit. Or is there? thanks |
 |
|
|
gpspassion
93394 Posts |
|
|
panyo
17 Posts |
Posted - 19 nov. 2007 : 08:34:35
|
quote: Originally posted by gpspassion
All I can say is that based on my testing of v1.94, pedestrian tracking si now on par with SiRFstarIII, see the link I gave above.
I am afraid I have found a way to reproduce the 'static nav' bug. I recently got an iTrek Z1. Here is what the bt747 program showed for version information: Model: 5202 (757/Z1 v2) Firmware: M-core_1.94
This device was very precise, and worked no problem with my Palm T3. Traking at walking speed was so good that I could map the floorplan in my home, and see myself walking around a parked car.
Then I tried to set it to 5Hz. Things did not go well. Now it displays the characteristics that seem to mimic the 'static nav' bug. When stationary, the bluetooth connection stays very still, even when I move the unit around several meters. When it does start to move spontaneously, it fluctuates wildly and still does not respond to true motion. Trough the USb connection, the behavior appears different. The track moves in regular intervals in one axis or the other, making rectangular patterns. When driving, the Bluetooth connection picks up and tracks just fine.
This persists at 1Hz and 5Hz.
I would be grateful for help, particularly from people with the same model, on what the default settings should be, what command sequences to send to see and set profile settings, and perhaps to figure out how to get this back to its original state.
Note that I got into trouble trying to make the settings with bt747 v. 1.12 with the latest Java update on an i386 Mac, so proceed carefully if you are thinking of doing the same, and/or let us know if you have done this with no problems. See http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=85368&whichpage=9 for more on the Mac issue. Edit: Somehow, things are OK again on the Bluetooth side. In my Gentoo PowerPC version of bt747, I tried setting some more things, erased the log, did an erase in the 'fmt' tab, tried setting 'test SBAS' and took out the battery (again). On restarting, the FMT settings were Time: 0.5 S, Fix: 1000ms and Distance: 10m.
On the shape of the USB trace, it seems the line segments reflect the minimum position tick, 0.01". |
Palm T3, iTrek Z1, Gentoo Linux PowerPC |
Edited by - panyo on 20 nov. 2007 06:10:02 |
 |
|
|
gpspassion
93394 Posts |
|
|
wobbletop
Canada
6 Posts |
Posted - 20 nov. 2007 : 20:26:58
|
BT is about 65Kbps real world. Which is about 8KBps (bytes per second). Divide that by 5 for 5Hz and you get 1600 bytes available for every 5Hz sample.
BT should be able to keep up. |
 |
|
|
panyo
17 Posts |
Posted - 21 nov. 2007 : 04:52:52
|
gpspassion, I unfixed it and it seems no longer broken :>. wobbletop, I measured a few seconds of my output as configured. They varied in size, perhaps given that some strings are reported with different frequency. The longest one second sections on USB included 2015 bytes, 2072 bytes, and 2125 bytes. They were gathered by tail -f /dev/ttyUSB0 > usbout.txt trimmed down to 1s and counted with wc -c usbout.txt
On bluetooth all the packets seemed to be the same number of lines. 10 seconds came to 19803 bytes, or 1980 per second.
This rate is with the unit right next to the Mac.
I then measured the same 10 seconds on both ports (one on the mac, and one in Gentoo). They all appeared to be the same number of lines, and diff showed both files identical. Their length was 20854, or 2085 per second.
The right thing would be to sit down with the field definitions for each string, my settings, and calculate what the sizes should be and do this more scientifically, but by both your accounts, I am pushing the maximum with the default settings.
There is a Perl program just announced in cooperation with mdeweerd's venerable bt747 for interacting with this unit ( http://sourceforge.net/forum/forum.php?thread_id=1874319&forum_id=696105 ). I am quite enthusiastic about this, being more experienced with Perl than with Java, (and Perl is Free) so if I get time, I might read that source for ideas on carrying out some tests more systematically.
|
Palm T3, iTrek Z1, Gentoo Linux PowerPC |
Edited by - panyo on 21 nov. 2007 04:57:38 |
 |
|
|
wobbletop
Canada
6 Posts |
Posted - 21 nov. 2007 : 16:52:52
|
If you were close to the limit on BT then you would be getting dropped packets and there would be differences in the logs. I'm not sure why USB was different length, maybe check the statement types that are coming back.
If you are getting 1980 bytes per second you are still well under the BT real world limit of 8KB/s. I still think there is plenty of bandwidth for BT to handle 5Hz samples. |
 |
|
|
ki4aoa
1 Posts |
Posted - 22 nov. 2007 : 03:26:20
|
panyo:
I too have noticed this screwy behavior with my qstarz bt-q1000. I am currently using bt. If I stay in motion, things work well. More times than not, if I let it sit in one position for more than 30 seconds, the lat/lon freezes. When this happens, I can then move the device around at walking speed for more than 50 or 60 feet and the speed shows 0 and the coords do not update. It really is fustrating, I can turn the pda software off and restart it and the problem remains, then only way that I can get the gps "unstuck" is to power off the gps.
Model:001D (Konet BGL-32) Firmware:M-core_1.94
I will try removing the battery tonight to see if it changes the device behavior.
-Marlin |
Edited by - ki4aoa on 22 nov. 2007 03:27:03 |
 |
|
Topic  |
|
|
|
| This page was generated in 3,7 seconds. |
 |
|