Error on ublox-gnss-driver - ver 1.1.1
# help
d
hi guys, im trying to use GPS functionality on a toit program, the ESP32 board im using has a NEO-6M (ublox) chip... Checking the packages list, i could find the ublox-gnss-driver.. after installing and trying to run sample code, i get the following error: \driver.toit:58:15: error: Type mismatch. Expected 'Task_'. Got 'Task' runner_ = task:: ^~~~ Compilation failed. Im running the code using the latest jag version... Version: v1.9.22 SDK version: v2.0.0-alpha.83 Build date: 2023-05-19T15:01:27Z Firmware updated accordingly Looking forward to your comments, regards
k
Thanks for reporting this. Will take a look on Monday!
Which version of the ublox-gnss-driver package are you using?
I feel like it just might be us not releasing the package: https://github.com/toitware/ublox-gnss-driver/compare/v1.1.1...main.
@diego.ar Oh, I see the version in the post title now. Thanks. Just pushed v1.1.2 with the latest bits from the main branch. We check for these issues on every commit to the Toit SDK (https://github.com/toitlang/toit/blob/master/external/CMakeLists.txt), but if we forget to push a new release of a package it doesn't help much 🙂
d
@kasperl thank you for the response, i just updated the pkg to version 1.1.2 and its working properly, great to have this fix...
btw, i ask one more thing, since the ublox-gnss-driver package has a i2c.toit file sample, but on the board im testing the GPS i need to use spi i tweaked the sample as follows, but the code is getting stucked at the driver.location --blocking lines.. am i wrong on anything?? thanks in advance // Copyright (C) 2021 Toitware ApS. All rights reserved. // Use of this source code is governed by a MIT-style license that can be found // in the LICENSE file. import gpio import serial import spi import ublox_gnss // SDA ::= gpio.Pin 12 // SCL ::= gpio.Pin 34 main: spi := spi.Bus --mosi=gpio.Pin 12 // MOSI --miso=gpio.Pin 34 // MISO --clock=gpio.Pin 5 // Clock device := spi.device //--cs=gpio.Pin 18 --frequency=100_000 //--address_bits=ublox_gnss.I2C_ADDRESS driver := ublox_gnss.Driver ublox_gnss.Reader device ublox_gnss.Writer device print "getting location" driver.location --blocking print "Took: $(driver.time_to_first_fix)" while true: location := driver.location --blocking print "Location: $location ($(max location.horizontal_accuracy location.vertical_accuracy))" driver.close
error stack.. ****************************************************************************** Decoding by
jag
, device has version ****************************************************************************** EXCEPTION error. Connection closed 0: tcp_error_ /net/modules/tcp.toit:208:3 1: TcpSocket_.ensure_state_ /net/modules/tcp.toit:75:14 2: TcpSocket.read /net/modules/tcp.toit:156:16 3: BufferedReader.more_ /reader.toit:82:22 4: BufferedReader.ensure_ /reader.toit:69:14 5: BufferedReader.can_ensure /reader.toit:109:5 6: Connection.read_request /connection.toit:138:20 7: Server.run_connection_. /server.toit:115:30 8: Task_.with_deadline_. /core/task.toit:203:16 9: Task_.with_deadline_ /core/task.toit:197:3 10: with_timeout /core/utils.toit:181:24 11: with_timeout /core/utils.toit:164:12 12: Server.run_connection_ /server.toit:114:7 13: Server.listen.... /server.toit:82:26 14: catch. /core/exceptions.toit:124:10 15: catch /core/exceptions.toit:122:1 16: catch /core/exceptions.toit:97:10 17: Server.listen... /server.toit:81:18 18: Server.listen.. /server.toit:78:38 19: Server.listen. /server.toit:98:37 20: Server.listen /server.toit:54:3 21: serve_incoming_requests /home/runner/work/jaguar/jaguar/src/jaguar.toit:401:10 22: run.. /home/runner/work/jaguar/jaguar/src/jaguar.toit:199:10 23: Task.group.. /core/task.toit:113:45 24: Task.group. /core/task.toit:110:26 ******************************************************************************
k
I think that error is unrelated to your GNSS code, but if you're not getting any locations printed before or after the stack trace then clearly something isn't working out.
I will have to take a look at the driver to figure out if more tweaks are necessary for I2C -> SPI conversion.
d
@kasperl im not getting up to now any locations printed, the message "getting location" does appear on the monitor screen from the board documentation i can see ESP32 RX - NEO-6M TX = 34 ESP32 TX - NEO-6M RX = 12 Max freq 10KHz
hey guys... @kasperl @floitsch i need to move forward on this.. any news/comments?? anything i can do on my side to go on? i could try to get a GPS device that i can use it on a I2C basis.. thanks in advance
f
Kasper has already left the office today. I hope he can have a look later today, but if not I will remind him tomorrow.
d
thank you @floitsch looking forward to this tomorrow, regards
k
Hi @diego.ar! It is a little bit hard to debug this without access to the right module, but maybe what we're lacking here is configuring the module to use SPI using a UBX message (UBX-CFG-PRT). I suggest adding some low-level logging in the ublox gnss driver, so we can see if we get any UBX messages over SPI.
f
Talked a bit with Kasper about this. So it looks like the driver just doesn't get any response. This could have multiple reasons: wrong pins, wrong speed, wrong module, bad code ... Do you have a link to the module you are using?
d
hey @kasperl @floitsch great to read from you... im running the code on a TTGO T-BEAM board, to be more specific (im attaching an image with the pinout specification) the board is ESP32 based, and has a Lora SX1276 chip and for GPS it holds a ublox NEO-6M, on the board i can see it's a NEO-6M-0-001, let me know if this information is enough
on the toit code, im including ublox-gnss-driver v1.1.2... you can see the code on this same post, i just copied and adapted the i2.toit sample that is included on the ublox-gnss driver
f
@diego.ar to me this looks like the NEO-6M is connected with a serial port.
However. I'm also seeing an AXP192, and after a bit of googling, this looks like it's a power-management unit. Looking further, it seems like lilygo's github example first configures the AXP before it communicates with the GPS module.
The AXP is also used in the m5stack-core2, so there exists already a package for it: https://pkg.toit.io/package/github.com%2Ftoitware%2Ftoit-axp192@v1.0.1
Unfortunately, the package isn't super intuitive (and I don't see a good way to make it much easier). You have to know how to configure the chip. I think the best approach is to copy the correct values from the lilygo example.
Copy code
axp.setPowerOutPut(AXP192_LDO2, AXP202_ON);
  axp.setPowerOutPut(AXP192_LDO3, AXP202_ON);
  axp.setPowerOutPut(AXP192_DCDC2, AXP202_ON);
  axp.setPowerOutPut(AXP192_EXTEN, AXP202_ON);
  axp.setPowerOutPut(AXP192_DCDC1, AXP202_ON);
We can definitely help you with that part.
d
ok @floitsch i'll give it a try...
f
@erikcorry wrote the package and used it for the m5stack-core2.
And I also had a look at some point.
So getting these 5 lines translated to Toit shouldn't be too hard.
Just for reference: here is the code for the m5stack core2: https://github.com/toitware/toit-m5stack-core2/blob/main/src/m5stack_core2.toit#L90
d
ok... let me get both packages and see how to configure the values for the AXP
ill do this now..
f
The first line (
axp.setPowerOutPut(AXP192_LDO2, AXP202_ON);
is almost certainly equivalent to https://github.com/toitware/toit-m5stack-core2/blob/main/src/m5stack_core2.toit#L223
And the next line the same 5 lines later.
d
sure...
f
actually. All the lines are just turning the power on. So it should be just the equivalent Toit functions.
d
ok..
f
I will make myself some food now (so maybe slow to respond), but I will check in a bit later again.
d
sure thank you very much for the support..
ill keep posting
o
I use GPS on the T-Beam. Quite straight forward. But I think you have to power it up first; i can have a look at my code if you need details.
d
hey @Oliver M ... sure great would be very useful
i just copied a i2c_scan.toit code that comes with the m5stack-core2 driver and im starting to test..
f
@Oliver M thanks for jumping in. I'm off for today, but it looks like there is progress. I will also look at the office if we have that board. (Unlikely, but you never know). And if not, I might order one.
d
// axp.setPowerOutPut(AXP192_LDO2, AXP202_ON); // axp.setPowerOutPut(AXP192_LDO3, AXP202_ON); // axp.setPowerOutPut(AXP192_DCDC2, AXP202_ON); // axp.setPowerOutPut(AXP192_EXTEN, AXP202_ON); // axp.setPowerOutPut(AXP192_DCDC1, AXP202_ON); POWER_OUTPUT_LDO2 POWER_OUTPUT_LDO3 POWER_OUTPUT_DC_DC2 POWER_OUTPUT_EXTEN POWER_OUTPUT_DC_DC1
@floitsch i have the constants out of the axp192 module.. i need to implement the set power output on now for the 5 lines... ill check on the @Oliver M code...
f
You should be able to import the package (similar to what the core2 code does). Basically install the package and then import it. But obviously also works if you just copy the constants.
d
i installed the package already yes..
f
The core2 code has functions for turning the power on. You can copy it from there.
d
jag pkg install github.com/toitware/toit-axp192
f
Looks good
d
great ill check... regards @floitsch
have good night
the code is not working yet.. after adding some adjusts, i reached the following: // Copyright (C) 2021 Toitware ApS. All rights reserved. // Use of this source code is governed by a MIT-style license that can be found // in the LICENSE file. import gpio import serial import spi import ublox_gnss import axp192 show * main: spi := spi.Bus --mosi=gpio.Pin 12 // MOSI --miso=gpio.Pin 34 // MISO --clock=gpio.Pin 5 // Clock device := spi.device --frequency=100_000 --address_bits=ublox_gnss.I2C_ADDRESS driver := ublox_gnss.Driver ublox_gnss.Reader device ublox_gnss.Writer device print "axp192 setup" set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO2 set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO3 set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC2 set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_EXTEN set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC1 print "getting location" driver.location --blocking print "Took: $(driver.time_to_first_fix)" while true: location := driver.location --blocking print "Location: $location ($(max location.horizontal_accuracy location.vertical_accuracy))" driver.close
this the program output.. [jaguar] INFO: program 7b3102e4-7193-675a-9383-81043cb7ab78 started axp192 setup getting location ****************************************************************************** Decoding by
jag
, device has version ****************************************************************************** EXCEPTION error. Connection closed 0: tcp_error_ /net/modules/tcp.toit:208:3 1: TcpSocket_.ensure_state_ /net/modules/tcp.toit:75:14 ....
i may have an issue with the ttgo tbeam module, since it should turn a red led on when gps module works, but no red led is on now on the module... i have only a light blue led on that means the battery is charging this turns on when i plug the USB cable to the computer
k
@diego.ar You probably want to power up the module using the AXP192 before you instantiate the driver. The call to
ublox_gnss.Driver
will try to communicate with the module and tell it to start sending NAV packets if I am not mistaken.
Copy code
print "axp192 setup"

  set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO2
  set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO3
  set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC2
  set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_EXTEN
  set_bits device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC1

  print "creating driver"

  driver := ublox_gnss.Driver
    ublox_gnss.Reader device
    ublox_gnss.Writer device

  print "getting location"

  driver.location --blocking
f
@diego.ar The AXP192 is on an i2c bus, not spi. This board uses three protocols/buses: - i2c to communicate with the AXP192. - spi to communicate with the LORA module. - serial to communicate with the NEO GPS. So you need to start by creating an i2c bus and device for the AXP192. From memory:
Copy code
import i2c
import uart
import gpio
import ublox_gnss
import axp192 show *

main:
  i2c_bus := i2c.Bus --scl=(gpio.Pin 22) --sda=(gpio.Pin 21)
  axp_device := i2c_bus.device 0x34
  set_bits axp_device POWER_OUPUT_CONTROL_REGISTER POWER_OUTPUT_LDO2
  ...   // Set the other power bits.
  axp_device.close
  i2c_bus.close

  // Communicate with the NEO over serial port.
  neo_uart := uart.Port --rx=(gpio.Pin 34) --tx=(gpio.Pin 12) --baud_rate=9600
  neo := ublox_gnss.Driver neo_uart neo_uart
  
  print "getting location"
  neo.location --blocking
  print "Took: $(neo.time_to_first_fix)"

  while true:
   location := driver.location --blocking
    print "Location: $location"
    sleep --ms=500

  neo.close
Again: this is from memory and untested. There might be some missing/wrong things, but it should give you the idea.
d
hi @kasperl @floitsch thanks for the update ill give it a try later today after 7pm (GMT-3 my timezone)..
this the code status now.. import i2c import uart import gpio import ublox_gnss import axp192 show * main: i2c_bus := i2c.Bus --scl=(gpio.Pin 22) --sda=(gpio.Pin 21) --frequency=400_000 axp_device := i2c_bus.device 0x34 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO2 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO3 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC2 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_EXTEN set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC1 // Communicate with the NEO over serial port neo_uart := uart.Port --rx=(gpio.Pin 34) --tx=(gpio.Pin 12) --baud_rate=9600 neo := ublox_gnss.Driver neo_uart neo_uart print "getting location" neo.location --blocking print "Took: $(neo.time_to_first_fix)" while true: location := neo.location --blocking print "Location: $location" sleep --ms=500 axp_device.close i2c_bus.close neo.close
this is not working yet..
i have been checking here https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/tree/master/examples/GPS/UBlox_BasicNMEARead where a basic NMEA read is available for arduino... i can see there are many settings that should be considered to setup the board, i will read this in detail and see what's missing, shouldn't be much more code just add the right configs... also i could not make the OLED screen work on this board (always coding on toit), the proper AXP192 config shall solve both situations (GPS and OLED).... thks
o
I’ll be back at my ESP tomorrow evening, will then be able to send you my code.
d
looking forward to this @Oliver M thks
in the meantime i keep going..
location = null read = PGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,3,1,10,01,,,18,09,,,20,11,,,18,12,,,19*7B $GPGSV,3,2,1 location = null read = PGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,2,1,07,01,,,14,09,,,20,11,,,15,13,,,14*71 $GPGSV,2,2,0 location = null read = PGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,2,1,05,01,,,11,09,,,17,14,,,09,16,,,21*79 $GPGSV,2,2,0 location = null read = PGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,1,1,04,01,,,09,14,,,08,16,,,20,29,,,20*74 $GPGLL,,,,,, location = null read = PGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,1,1,03,01,,,08,16,,,18,29,,,20*74 $GPGLL,,,,,,V,N*64
import i2c import uart import gpio import ublox_gnss import axp192 show * main: i2c_bus := i2c.Bus --scl=(gpio.Pin 22) --sda=(gpio.Pin 21) --frequency=400_000 axp_device := i2c_bus.device 0x34 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO2 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_LDO3 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC2 set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_EXTEN set_bits axp_device POWER_OUTPUT_CONTROL_REGISTER POWER_OUTPUT_DC_DC1 // Communicate with the NEO over serial port neo_uart := uart.Port --rx=(gpio.Pin 34) --tx=(gpio.Pin 12) --baud_rate=9600 --data_bits=8 --parity=uart.Port.PARITY_DISABLED --stop_bits=uart.Port.STOP_BITS_1 neo := ublox_gnss.Driver neo_uart neo_uart sleep --ms=1500 print neo.location r/string := neo_uart.read.to_string_non_throwing l := neo.location while true: r = neo_uart.read.to_string_non_throwing print "read = " + r l = neo.location print "location = $l" sleep --ms=500 axp_device.close i2c_bus.close neo.close
the uart read is throwing data, the problem seems to be with the gnss driver
k
Looks like you are getting NMEA-encoded readings over the UART? The driver tries to read UBX packets. Maybe the NEO needs to be configured as per my previous message?
d
yes, the reading is getting NMEA-encoded messages. Ok i understand what the gnss driver expects, so according to what i can see on ublox PDF, i should compose a CFG-PRT to configure outProtoMask to force UBX format messages.. the sequence starts with 0xB5 0x62 0x06 0x00 .. as i can see on the doc... ill do some testing, thks
hey guys, i could configure the ublox and i see only UBX messages now when reading from uart.. nevertheless the driver.location --blocking is no yet responding.. any clue? thks... [jaguar] INFO: program 61a53f34-1ff3-c5a3-2fbb-64c01bdf2727 started configure ublox ublox response - Length = 20 #[0xb5, 0x62, 0x05, 0x01, 0x02, 0x00, 0x06, 0x01, 0x0f, 0x38, 0xb5, 0x62, 0x05, 0x00, 0x02, 0x00, 0x06, 0x01, 0x0e, 0x33] Location null UBX INFO - Length = 24 #[0xb5, 0x62, 0x01, 0x03, 0x10, 0x00, 0x00, 0x47, 0x44, 0x0b, 0x00, 0x4c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xcb, 0xdd] #[0x65, 0x00, 0x03, 0xae] Location null UBX INFO - Length = 24 #[0xb5, 0x62, 0x01, 0x03, 0x10, 0x00, 0xd0, 0x4e, 0x44, 0x0b, 0x00, 0x4c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9b, 0xe5] #[0x65, 0x00, 0xb2, 0x6f] Location null UBX INFO - Length = 24 #[0xb5, 0x62, 0x01, 0x03, 0x10, 0x00, 0xa0, 0x56, 0x44, 0x0b, 0x00, 0x4c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x6b, 0xed] #[0x65, 0x00, 0x62, 0x3f] Location null
k
Can you share your setup code? I'm curious to see where you configure using UBX CFG-PRT.
d
sure...
k
It feels like you're making good progress!
I hope we can get the locations through soon 🙂
d
yes indeed.. i spent many hours over the code... had to check the fletcher algorithm on a spreadsheet to be sure i was calculating right the checksum...
also... thanks for all the support.. couldnt make it without your help!
sorry is a protoype.. i need to add comments, etc
k
Of course. I wonder if https://github.com/toitware/ubx-message/blob/main/src/ubx_message.toit could be useful for you?
You'll probably need to extend the Message class to add a CfgPrt specialization.
But at least it might give you some help with the checksums, etc.
d
sure great, thks @kasperl .. late here ill try tomorrow and let you know
k
I'll take a look at your code in a bit and see if anything pops out. You don't really need to use the ubx_message package, but it might be more convenient.
d
ok great!
k
So overall, we need to get to a point where there is only one reader/writer on the UART at the same time. As far as I can tell, the driver will try to configure, read, and write, so your loop with the call to
neo_uart.read
is likely to conflict with this. The driver already has a loop that tries to read from the UART: https://github.com/toitware/ublox-gnss-driver/blob/main/src/driver.toit#L60. It might be better to try to add a bit of debugging logging where the UBX message has been read: https://github.com/toitware/ublox-gnss-driver/blob/main/src/driver.toit#L162.
You can try to change it to something like this:
Copy code
e := catch: 
          message := ubx_message.Message.from_reader reader_
          print "Received message = $message"
          return message
o
Sorry, am only now back; do you still need this, or have you got it running yet?
d
hey @Oliver M no problem at all, if you post your code it will sure be useful.. thks
hey @kasperl ... i added the lines you suggested, here is the output im getting [jaguar] INFO: program f31ea098-4970-fa3a-07a1-9213a48cf581 started configure ublox time to first fix: 0s signal_quality: 0.0 satellites_in_view: 0 known_satellites: 0 Location 1: null Received message = UBX-NAV-STATUS Received message = UBX-ACK-0x01 Received message = UBX-ACK-0x00 Received message = UBX-ACK-0x00 Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Location 2: null Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Location 3: null Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Location 4: null Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS Received message = UBX-NAV-STATUS
i added a print of the diagnostics object time to first fix, etc.. the location is getting null the message := ubx_message.Message.from_reader reader_ is getting the right UBX-NAV-STATUS message
also if i add a --blocking to the .location method the code waits there.. i presume the monitor.Latch is failing at https://github.com/toitware/ublox-gnss-driver/blob/main/src/driver.toit#L51
oh... i realize the problem is im not getting UBX-NAV-PVT messages.. just UBX-NAV-STATUS... im checking ublox documentation
k
It might be useful to see if you can get some signal strength/quality numbers out. Not sure what NAV-STATUS contains. I remember we once had huge issues getting a fix because of antenna issues.
d
ok thks @kasperl ill try to get the signal strength/quality numbers, perhaps it's an antenna issue (im indoor) i can see here https://portal.u-blox.com/s/question/0D52p00008HKDqxCAH/neo-6m-issue-with-navpvt-not-acknowledged that UBX-NAV-PVT is not supported by the u-Blox 6 Protocol Specification i think... - may be use NAV-POSLLH, if this the case ill have to configure the polling rate (CFG-MSG) - switch to NMEA and just retrieve the lat/long positions from there ill keep doing
k
I think you're getting really close!
d
i hope so 😅
k
I took a quick look and I think it should be relatively straightforward to ask for NAV-POSLLH packets every second. You're right that we just wait (forever) on the latch operation, if the location is never set because you don't get any NAV-PVT packets.
You're not getting any NAV-SAT packets either, right?
d
ok great @kasperl.. no, im not getting NAV-SAT messages either; it seems NAV-PVT is supported starting on ublox 7 and NAV-SAT on ublox 8, NAV-POSLLH should be a good way to go
almost there... NAV-POSLLH configured properly, added a class NavPosLLH extends Message at ubs_message.toit need to parse the payload as expected i think and it should work configure ublox Received message = UBX-ACK-0x01 Received message = UBX-ACK-0x01 Received message = UBX-ACK-0x00 Received message = UBX-ACK-0x00 Received message = UBX-NAV-STATUS Received message = UBX-NAV-POSLLH Received message = UBX-NAV-STATUS Received message = UBX-NAV-POSLLH Received message = UBX-NAV-STATUS Received message = UBX-NAV-POSLLH Received message = UBX-NAV-STATUS
k
💥
d
hey.. up and running 😀 ! NAV-POSLLH message is parsing ok, also outdoor solved signal issues.. [jaguar] INFO: program 4d45da00-6e1d-c71e-7561-1fb94096dafd started configure ublox Location 1: null Location 2: 34.5........S, 58.4.........W Location 3: 34.5........S, 58.4.........W Location 4: 34.5........S, 58.4.........W .... one comment/question, on the NAV-PVT message UTC time and date is available on the payload, NAV-POSLLH does not hold this information only a itow field (GPS millisecond time of week)... i forced a Time.now instead on the GnssLocation, as stated below: process_nav_posllh_ message/ubx_message.NavPosLLH: location_ = GnssLocation Location message.lat / COORDINATE_FACTOR message.lon / COORDINATE_FACTOR message.height_msl.to_float / METER_TO_MILLIMETER Time.now message.horizontal_acc.to_float / METER_TO_MILLIMETER message.vertical_acc.to_float / METER_TO_MILLIMETER waiters := waiters_ waiters_ = [] waiters.do: it.set location_ this is not accurate.. any suggestions? i see there is a different UBX message NAV-TIMEUTC that could be used... thank you
k
I think you need to combine NAV-TIMEUTC and the time-of-week timing in the NAV-POSLLH for this to be accurate. So maybe you should poll for NAV-TIMEUTC first and store that. I think it contains the time-of-week too, so you can compute the beginning of the week time that you can add to all subsequent time-of-week timestamps that arrive in NAV-POSLLH packets. You'll need to keep track of the last time-of-week value received to see when it wraps around (the new value is smaller than the previously received value) and at that point you should increase the beginning of the week time by a week. Pretty handwavy 🙂
f
@diego.ar We got a TTGO T-BEAM delivered yesterday evening. If you still need help let us know, and I will try to play with it.
2 Views