Most recent activity
-
Here are a couple of plots showing the result using $PCAS15,4,7FFFF*06 versus $PCAS15,4,FFFF*31. Not a real scientific test since the numbers of satellites used are different, but it does show that the first test was not a one-off fluke.
The first plot shows the $PCAS15,4,7FFFF*06 command.
-
I went for a nice run this morning and the area of the run had good GPS horizons and 5-6 satellites were used during the run. Subsequent viewing of the recorded track revealed position errors that were certainly greater than a few meters.
I really did not think SBAS was working and so I wanted to try using the CAS command ($PCAS15,4,FFFF*31) that I had originally used and had great results with on my 2km test area.
So, I reverted back to that command and ran the 2km test where I went up the hill on one side of the road and back down on the other side (always facing traffic).There were 8 satellites used in this test. The distances measured were good and the plotted positions showed a significant improvement over the last run along this track (using my revised CAS command) and almost as good as the initial SBAS test. The CASIC spec uses this command ($PCAS15,4,FFFF*31) as an example, so maybe my modified command to accommodate more satellites is invalid even though there are more satellites actually in use.
There are various reasons that could explain the differences and as Gordon noted, a head-to-head test is really needed. For what it's worth, I'll continue using this iteration for the next few runs to see how things go. When plotting a run on Google maps, it is easy to see the errors.
-
I really don't understand the conditions under which the PCAS commands are effective. I have spent many hours in trial and error experimentation. For example turning NMEA message on and off only works under certain conditions. Also, using D29 vs setGPSPower makes a difference. I found that when D29 is used to turn on GPS, GPS still runs after exiting the app. isGPSon() does not report correctly in that case, either.
I did another 2km test yesterday over the same course and I found the position errors were larger than from two days ago. The distance measured was still fairly accurate. Looking at the satellites used, yesterday there were 5, while two days ago, there were 9 - 12 satellites used, with 9 satellites used only for a few seconds.
-
I have looked into the problem that uname had with this app; I think that it is caused by the GPS not being on. It works fine with my Bangle 2 with 2v12.92 but I don't know if that is the difference.
In order to make the CAS commands to the GPS to work, I was writing to D29 to turn GPS off and on. I had found that turning D29 off was necessary to get the CAS commands to work. Now, I have found that setGPSPower(1) works for turning GPS on and keeping the changes. So, I have made a new revision, 0.70. Hopefully, it solves uname's problem.
On the whole, I have found that a lot of trial and error was required, even after much research to customize the GPS system. It's been quite the experience. Now, I hope I haven't broken something else. I will run a quick test tomorrow (today now, actually) to see if the GPS will still produce the nice results.
-
I have used my GPS app twice now since I added the command to turn on the use of SBAS satellites and I think AT6558 may be actually using them. This is my impression after looking the results of two sessions with the changed app. I also tried logging NMEA messages and checking for the presence of the SBAS satellites but I can't find any sign of them. I use GPS and Beidou satellites and those are present in the NMEA messages.
The NMEA message logs shows that the AT6558 software version is SW=URANUS5,V5.3.0.0. A CASIC spec that I have says:
CAS15 Satellite system control commands, you can configure whether to receive any satellite in the system Subsequent versions of V5200 support this commandAn example of this command from the spec:
$PCAS15,4,FFFF*31, turn on satellites 1-16 of SBAS, that is, PRN=120-135So, it would appear that the AT6558 in the Bangle.js 2 supports SBAS corrections. Since WAAS (SBAS) can be used for aircraft landing systems, the typical position error of 2m horizontally would be quite an improvement. But, as I could not find any evidence that the Bangle can actually use SBAS, I decided to try it out and see what happens.
Unfortunately, I did not do this test in a controlled manner, but for me the results show much fewer and smaller position errors than what I had experienced before. So far, I have recorded a short 2km walk going up a hill on the left hand side of the road, and then turning around at the 1km mark and returning to the start point on the opposite side of the road (always on the left facing traffic). The recorded tracks show no crossovers, although there is one small section where there was convergence. I then mapped this walk online on the gmap-pedometer site. The distances compare favourably.
Since I added the PCAS15 command to the app, I discovered that there are more than 16 SBAS satellites in service. I have changed the PCAS15 command to:
$PCAS15,4,7FFFF*06so 19 satellites (up to PRN 138) can be used. With this new version, I ran just over 10km this morning in hilly terrain with varied tree cover. The horizons were variable so all in all, not great GPS environment. Viewing the track up close on a computer screen shows no gross errors. This is definitely a noticeable change from previous runs in this area. I am very impressed with the Bangle.js 2 GPS now.
Once again, this was not a controlled test, but there is a definite improvement over my previous uses of this app. It may be coincidental with my software changes, but I just want to let people know that this Bangle.js 2 watch is capable of good positioning. Also, maybe others will be encouraged to try this PCAS15 command. It would be good to know if it actually works.
-
Here are some photos showing what the display should be on start-up.
- On start-up waiting for GPS fix
- Once fix is achieved, the averaged GPS and barometric altitudes are displayed
- After swiping up or down on the altitude screen, the timing/recording starts and the Distance/Pace screen is shown
- On start-up waiting for GPS fix
-
I just went online, deleted the app from my Bangle and reloaded it, and tested it. There were no problems. I wonder what happened to your installation.
Judging from your error messages, parts of the app are missing. Maybe try reinstalling it.
-
I made a couple to changes to the app today.
Race uses GGA NMEA messages so I turn off all other NMEA messages. The app now turns all the NMEA messages back on when exiting.
I noticed that the GPS chip has potential for using SBAS satellites for improved position accuracy. I don't know if the Bangle has the capability or not but the app now issues a $PCAS15,4,FFFF*31 command to turn these satellites on.
I ran a 9km circuit this morning and I am quite happy with the recorded track. There were between 6 and 7 satellites used during the run. The attached plot shows a detail of part of the run. If I can get similar results on all my runs, I would be very happy.
One thing to note: my run started on a downtown street (two traffic lanes with parallel parking on each side) with two to three storey buildings on each side and the GPS altitude was around -90m at the start. This resolved itself after a few blocks out of the "canyon", but the start elevation for the run was set at -90m.
I added a mode to the app to be able to switch SBAS on and off (at least, issue the commands) during a run. I tested it this afternoon when 8 satellites were used. The tracks after the SBAS on command qualitatively look better than the tracks after issuing the SBAS off command, but the differences are not huge. Having 8 satellites will generate good results.
In my log file, though, I did notice that after sending a SBAS command to the GPS, it undergoes an initialization and sends out the usual startup $GPTXT messages. So, the $PCAS15,4 command is doing something.