Release: JField 3.0.2.1151 and Linux OS 4.4.167.11

Michael Stazhkov

Developer
Staff member
5PLS
JField 3.0.2.1151:
- added: Undo for point/line delete actions
- added: possibility to delete polyline segment
- added GNSS firmware automatic re-start if GNSS FW doesn't response
- improved: Draw functionality (map screen)
- improved: Snap functionality (map screen)
- fixed: TCP server crashes when using as Base
- fixed: corrections stream reestablishing after connection lost (when using as Base)
- fixed: crash during reboot
GNSS FW 3.7.6.190524:
- fixed firmware crash on some devices
Linux OS 4.4.167.11:
- added: Factory recovery tool. Allows to do recovery to Release / PreRelease / Testing versions of software through internet. Customer data will not be touched.
- fixed triumph-isp library: fixed KMS PrimaryBuffer::Capture (JField occasional crash when getting screenshot in parallel with RAMS)
- fixed GBM library: fixed gbm_bo_mmap
- fixed triumph-net library: fixed WiFi tethering helpers (JField occasional crash on WiFi screen)
- updated qmi, mbim libraries
- updated gnss_link driver: implemented UAPI for management through IOCTL of the tty device
- updated qmi_wwan driver: fixed to use in the RAW-IP mode (Linux OS crash when working as Base)
- updated usbnet driver: fixed read/write commands
- implemented safe reboot of the gnss module
- disabled software flow control on the tty input queue
- enabled throttling support on each of the tty input queue with management through sysfs
GSM (MC7304) 5.5.78.0:
- Sierra Wireless Generic approved firmware
 

Michael Stazhkov

Developer
Staff member
5PLS
To run Factory recovery tool:
- press Home button during Triumph LS loading. It will enter boot menu
- select "Reset to Factory Image" button.
- answer "Yes". It will run Factory Recovery Tool.

If Ethernet cable is not connected and WiFi connection was not setup previously you can setup WiFi connection in "Network settings" screen.
To select Release / PreRelease / Testing versions go to "Software settings" screen.
For downloading and installing software go to "Software recovery" screen.
To continue booting press button in the top right corner.
Reply
 

Michael Stazhkov

Developer
Staff member
5PLS
GNSS FW was returned to previous Release version (3.7.6.190416) as firmware crash (3.7.6.190524) was caught on some devices.
 

Felix Wolter

New Member
Hej I seem to be stuck in an update loop...
I updated via the "Support" function of the LS to:
- J-Field 3.0.2.1151
- GeoData 2.4.7.41106
- GNSS 0.0.0.0 / 3.7.6.190416
- Linux OS 4.4.167.11
and no matter how often I install the update and reboot, the software keeps on saying that a update is avaible.

Furthermore the system makes unmotivated sounds, ghost clicks and the GPS, SIM and RTK icons on the home screen have a lock symbol next to it!
Tried the Factory reset as described above, but it didnt change anything. Before I do attempt to completely re-install the OS I wanted to ask for advice?
I am still very new to the system so please be patient if i miss something obvious...
 

Michael Stazhkov

Developer
Staff member
5PLS
Hej I seem to be stuck in an update loop...
I updated via the "Support" function of the LS to:
- J-Field 3.0.2.1151
- GeoData 2.4.7.41106
- GNSS 0.0.0.0 / 3.7.6.190416
- Linux OS 4.4.167.11
and no matter how often I install the update and reboot, the software keeps on saying that a update is avaible.

Furthermore the system makes unmotivated sounds, ghost clicks and the GPS, SIM and RTK icons on the home screen have a lock symbol next to it!
Tried the Factory reset as described above, but it didnt change anything. Before I do attempt to completely re-install the OS I wanted to ask for advice?
I am still very new to the system so please be patient if i miss something obvious...
Could you connect your receiver to RAMS (Support -> Remote Assistance) and tell your device serial number.
 

Michael Stazhkov

Developer
Staff member
5PLS
- GNSS 0.0.0.0 / 3.7.6.190416
Furthermore the system makes unmotivated sounds, ghost clicks and the GPS, SIM and RTK icons on the home screen have a lock symbol next to it!
On some devices current released GNSS FW can't start. We are working on the issue and temporary solution is to install PreRelease version of GNSS FW. For that I am going to disable update of JField and Linux OS, switch update to PreRelease branch, install only GNSS FW and switch back to Release.
 

Jim Frame

Active Member
After updating to this new release, I noticed that I had a new export option: Star*Net GPS format. I've been happy with the g-file export, but decided to see if could skip a step by exporting direct to the Star*Net format. I still need to search-and-replace the base station name (which is easy) to make the file compatible with Star*Net, but I'm wondering about a couple of things:

1. There's an included C (coordinate) record for the base station, which in my case today was an RTN base (single-vector, not virtual). The lat/long are expressed in decimal degrees, while my version of Star*Net (v6.0 -- older, I realize) only accepts DDD.MMSS.xxxxxx or gons. I don't know if newer versions of Star*Net accept decimal degrees, but in any case this would be a user-specified option. Perhaps in a future version of the export engine it could insert an inline option to define the angular units.

2. The base station positional values in the exported file are close to, but not the same as, the published position. Is the base position taken directly from the transmitted data stream without any conversion? I'm wondering why there's a discrepancy.

Thanks!
 

Andrey Zhiganov

Active Member
5PLS
The base station positional values in the exported file are close to, but not the same as, the published position. Is the base position taken directly from the transmitted data stream without any conversion? I'm wondering why there's a discrepancy.
Hello, Jim. Could you give me your project and StarNet file to investigate?
There's an included C (coordinate) record for the base station, which in my case today was an RTN base (single-vector, not virtual). The lat/long are expressed in decimal degrees, while my version of Star*Net (v6.0 -- older, I realize) only accepts DDD.MMSS.xxxxxx or gons. I don't know if newer versions of Star*Net accept decimal degrees, but in any case this would be a user-specified option.
I will add.
 

Jim Frame

Active Member
Jim, what is the formula to convert to the format?
I can only speak to Star*Net v6 and earlier, but it uses a dot to delimit degrees, then two digits for minutes, two digits for seconds, and the remaining digits represent decimal seconds. So 121°45'04.382789" would be represented as 121.4504382789 (the format I show in my original post is incorrect, as I inadvertently put an extraneous dot in the seconds).

Also, a lat/long position wouldn't be in a C record, it would be in a PH record (Position and Height) representing lat, long and ellipsoid height. C records are reserved for grid coordinates, at least in v6.0 and earlier. (I tried to find a user manual for the new version online to see if any of this has changed, but was unsuccessful.)


What the correct values must be?
The position published for the base station in my project (UCD1) is shown in the following PH record:

PH UCD1 38.3210451972 121.4504382789 -0.015 ! ! !

The C record generated by J-Field is:

C UCD1 38.536240 -121.751235 -0.539125 0.00000000 0.00000000 0.00000000 '

Thanks!
 

Jim Frame

Active Member
I should note that Star*Net also accepts Position values in hyphen-delimited format, so that the PH record shown above would be as follows:

PH UCD1 38-32-10.451972 121-45-04.382789 -0.015 ! ! !

I found this format to be more difficult to use in automated conversions, so I stick with the dot-delimited format.

I should also note that the height value in my PH record is expressed in meters, while the J-Field conversion is given in feet, which is consistent with the units setting in my J-Field project.
 

Jim Frame

Active Member
I hit the same points again today, and see that the Star*Net export shows a different position for the same RTN base:

C @1 38.536240 -121.751235 -0.539125 0.00000000 0.00000000 0.00000000 '
C @6 38.536237 -121.751217 -0.015200 0.00000000 0.00000000 0.00000000 '

It seems to me that it should be extracting the base position from the RTN message.

I've attached today's files, with the Star*Net extension changed to .txt.
 

Attachments

Andrey Zhiganov

Active Member
5PLS
I should also note that the height value in my PH record is expressed in meters, while the J-Field conversion is given in feet, which is consistent with the units setting in my J-Field project.
The height always is recorded in meters.
From documentation: "Angular values may be entered in “D-M-S” format (123-44-55.66) or “packed” format (123.445566), the format commonly used by calculators. Angles may also be entered in GONS."
I added these formats.
The position published for the base station in my project (UCD1) is shown in the following PH record:
PH UCD1 38.3210451972 121.4504382789 -0.015 ! ! !
Now for DD.MMSSss:
C @6 38.321045197 121.450438279 -0.015200 0.00000000 0.00000000 0.00000000 'DefCode
I hit the same points again today, and see that the Star*Net export shows a different position for the same RTN base:
C @1 38.536240 -121.751235 -0.539125 0.00000000 0.00000000 0.00000000 '
C @6 38.536237 -121.751217 -0.015200 0.00000000 0.00000000 0.00000000 '
I will ask for @Vladimir Prasolov to investigate it in more details.
 

Vladimir Prasolov

Well-Known Member
5PLS
Hi Jim,
I looked into both projects and found that surveyed points use same @1 base with equal coordinates. Points @1 and @6 has huge 1.6 meter separation.
8942


In following screenshots we see same coordinates for base station in both projects:

8943


8944


Maybe in second project you do not use newly received RTN base station for surveying and @6 is same base as @1. In that case, I think, that huge offset could be due to Reference Frame coordinate systems mismatch. For example RTN broadcast base position in WGS84, but we set RTN Reference Frame to NAD83. RTCM3 has no information what reference frame is used for base station. It should be WGS84. But many RTN stations transmit local coordinates for "convenience", for example, NAD83. Jim, please verify those settings.
 

Jim Frame

Active Member
The first set of files were from the first day of observations, the second set of files were from the second day of observations. It's all one project, with no changes to settings in between days -- on Day 2 I just turned the receiver on and started collecting shots in the same project. That's why I'm perplexed by the difference in base station coordinates, not to mention the discrepancy between exported base position and published base position.
 
Top