search

sparkfun / SparkFun_Ublox_Arduino_Library

Library to control UBX binary protocol and NMEA over I2C on Ublox GPS modules
Other
144 stars 84 forks source link

Communication will no begin with DUE Wire1 #163

Closed bvernham closed 3 years ago

bvernham commented 3 years ago

Subject of the issue

Describe your issue here. If you reference a datasheet please specify which one and in which section (ie, the protocol manual, section 5.1.2). Additionally, screenshots are easy to paste into github.

Your workbench

PaulZC commented 3 years ago

Hi @bvernham , Please take a look at this issue and please try the suggestions: https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/issues/129 If those do not work, please try inserting myGPS.enableDebugging(); before myGPS.begin(); and post the debug messages here. Thank you, Paul

bvernham commented 3 years ago

129 is using Serial port but I am using I2C so buffer should not be an issue.

My first command after begin is: myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise) Also, the GPS is not the first wire device to initialize. I am initializing the QWIIC EEPROM first so I am not quite sure how #129 suggestions help in this situation? If I am missing something out of #129, please let me know but if not will do the debug post the debug output.

PaulZC commented 3 years ago

Hi @bvernham , OK. I don't have a Due or your other boards here, so I can't replicate your set-up. But I will help if I can. Please do try enableDebugging. It may give us some clues. I'd like to see if .begin is failing. Also, have you tried communicating with the NEO on its own (without any other boards connected)? Best wishes, Paul

PaulZC commented 3 years ago

Also, example2 may not be the best choice for you. Are we talking about the same example2? Example2_NMEAParsing? That example won't work if you have called myGPS.setI2COutput(COM_TYPE_UBX); as there will be no NMEA output.

Also, please check that you are calling myGPS.begin(Wire1);

It may help if you can post your code here too.

bvernham commented 3 years ago

Of course I tried all the boards one by one.

None of the other boards have issue with Wire1 (LCD/EEPROM as QWIIC boards) so this is why this is soooo strange.

Code is example 3 modified by using wire1. PS is I use myGPS.begin(Wire1) this complier complains no such function so I include the default wire address for the neo.

I was trying example 3 not example 2.
`#include //Needed for I2C to GPS

include "SparkFun_Ublox_Arduino_Library.h" //http://librarymanager/All#SparkFun_Ublox_GPS

SFE_UBLOX_GPS myGPS;

long lastTime = 0; //Simple local timer. Limits amount if I2C traffic to Ublox module.

void setup() { Serial.begin(115200); while (!Serial); //Wait for user to open terminal Serial.println("SparkFun Ublox Example");

Wire1.begin();

if (myGPS.begin(Wire1,0x42) == false) //Connect to the Ublox module using Wire port { Serial.println(F("Ublox GPS not detected at default I2C address. Please check wiring. Freezing.")); while (1); }

myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise) myGPS.saveConfiguration(); //Save the current settings to flash and BBR }

void loop() { //Query module only every second. Doing it more often will just cause I2C traffic. //The module only responds when a new position is available if (millis() - lastTime > 1000) { lastTime = millis(); //Update the timer

long latitude = myGPS.getLatitude();
Serial.print(F("Lat: "));
Serial.print(latitude);

long longitude = myGPS.getLongitude();
Serial.print(F(" Long: "));
Serial.print(longitude);
Serial.print(F(" (degrees * 10^-7)"));

long altitude = myGPS.getAltitude();
Serial.print(F(" Alt: "));
Serial.print(altitude);
Serial.print(F(" (mm)"));

byte SIV = myGPS.getSIV();
Serial.print(F(" SIV: "));
Serial.print(SIV);

Serial.println();

} }` So I enabled debug on SerialUSB and it made me a liar...started to communicate. SparkFun Ublox Example

Sending: CLS:CFG ID:RATE Len: 0x0 Payload: sendCommand: Waiting for ACK response checkUbloxI2C: u-blox bug, length lsb is 0xFF checkUbloxI2C: Reading 24 bytes Incoming: Size: 6 Received: CLS:CFG ID:RATE Len: 0x6 Payload: F4 1 1 0 1 0 packetCfg now valid packetCfg classAndIDmatch Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: valid data and valid ACK received after 110 msec

Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 0 sendCommand: Waiting for ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 38 bytes Incoming: Size: 20 Received: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 1 0 0 0 0 0 packetCfg now valid packetCfg classAndIDmatch Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: valid data and valid ACK received after 119 msec

Sending: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 1 0 0 0 0 0 sendCommand: Waiting for ACK response checkUbloxI2C: Bytes available error:13666 checkUbloxI2C: Large packet of 13666 bytes received Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED packetCfg now valid packetAck now valid packetAck classAndIDmatch Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED packetCfg now valid packetAck now valid packetAck classAndIDmatch Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED packetCfg now valid packetAck now valid packetAck classAndIDmatch Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED packetCfg now valid packetAck now valid packetAck classAndIDmatch Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED packetCfg now valid packetAck now valid packetAck classAndIDmatch waitForACKResponse: no data and valid ACK after 2829 msec

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: IGNORED sendCommand: Waiting for ACK response checkUbloxI2C: u-blox bug, length lsb is 0xFF checkUbloxI2C: u-blox bug, length lsb is 0xFF checkUbloxI2C: Reading 10 bytes Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 9 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: no data and valid ACK after 209 msec getPVT: Polling

So I thought, great, disabled debug and now I am right back to: SparkFun Ublox Example Ublox GPS not detected at default I2C address. Please check wiring. Freezing.

Is there some extra delay with running debug vs not running debug that could cause this?

Thanks

Bruce

PaulZC commented 3 years ago

Hi Bruce, I think you have almost solved this. What happens if you insert a delay(1000); after Wire1.begin(); but before myGPS.begin? Best, Paul

PaulZC commented 3 years ago

Ah, OK. The "Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED" is a big clue. It looks like you have "automatic" PVT messages enabled - maybe from an earlier example? If you enable automatic PVT messages and then call myGPS.saveConfiguration(); //Save the current settings to flash and BBR the automatic PVT message configuration gets saved too. So, your module is starting PVT messages automatically when it powers on - and those are probably preventing the .begin from being executed correctly.

Please try this:

  // Uncomment the next line if you want to reset your module back to the default settings with 1Hz navigation rate
  myGPS.factoryDefault(); delay(5000);

  myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise)
  myGPS.saveConfigSelective(VAL_CFG_SUBSEC_IOPORT); //Save the communications port settings to flash and BBR

I prefer to use saveConfigSelective instead of saveConfiguration (which saves everything).

Best, Paul

bvernham commented 3 years ago

But I had the same issue before I was using autoPVT.The issue goes back to when I first un-boxed it.Again, it is only Wire1 with the SerialUSB and not Wire with either Serial port or Wire1 with the programming port.So I can disable autoPVT but I believe I will continue to have the same issue.

---------- Original Message ---------- From: Paul notifications@github.com To: sparkfun/SparkFun_Ublox_Arduino_Library SparkFun_Ublox_Arduino_Library@noreply.github.com Cc: bvernham bvernham@juno.com, Mention mention@noreply.github.com Subject: Re: [sparkfun/SparkFun_Ublox_Arduino_Library] Communication will no begin with DUE Wire1 (#163) Date: Wed, 23 Dec 2020 07:37:42 -0800

Ah, OK. The "Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: IGNORED" is a big clue. It looks like you have "automatic" PVT messages enabled - maybe from an earlier example? If you enable automatic PVT messages and then call myGPS.saveConfiguration(); //Save the current settings to flash and BBR the automatic PVT message configuration gets saved too. So, your module is starting PVT messages automatically when it powers on - and those are probably preventing the .begin from being executed correctly. Please try this: // Uncomment the next line if you want to reset your module back to the default settings with 1Hz navigation rate myGPS.factoryDefault(); delay(5000); myGPS.setI2COutput(COM_TYPE_UBX); //Set the I2C port to output UBX only (turn off NMEA noise) myGPS.saveConfigSelective(VAL_CFG_SUBSEC_IOPORT); //Save the communications port settings to flash and BBRI prefer to use saveConfigSelective instead of saveConfiguration (which saves everything). Best, Paul

bvernham commented 3 years ago

OK, I did the factory reset.Ran example 3 on SerialUSB with Wire no problems.Ran example on SerialUSB with Wire1 SparkFun Ublox Example Ublox GPS not detected at default I2C address. Please check wiring. Freezing. Tried adding the delay(1000) after the Wire1.begin Wire1.begin(); delay(1000); if (myGPS.begin(Wire1,0x42) == false) //Connect to the Ublox module using Wire port// { Serial.println(F("Ublox GPS not detected at default I2C address. Please check wiring. Freezing.")); while (1); }Same result... SparkFun Ublox Example Ublox GPS not detected at default I2C address. Please check wiring. Freezing. Other thoughts? ThanksBruce

PaulZC commented 3 years ago

Hi Bruce, Weird... I don't have a Due (Cortex-M3), so I can't replicate this... I have had a look at the variant.h for the Due and I'm not seeing anything unusual in there. It looks like both Wire and Wire1 have hardware support. So I can't explain why Wire works and Wire1 does not. I don't think this is a problem with the u-blox library. It must be something subtle to do with the TwoWire implementation on Due. I will leave this issue open in case anyone else can help, but I don't think I can give you any more help with this. Sorry! Best wishes (& Merry Christmas), Paul

bvernham commented 3 years ago

It must be some little quick with the UBLOX Two wire and DUE Wire1 as Wire one work find for the Sparkfun QWIIC EEPROM, Adafruit BMP390L and the Sparkfun QWIIC RGB LCD. It is only the ublox I am struggling with.Lucky Wire works just fine. Also, has any one considered implementing the UBLOX ODO functionality in the library? Thanks Bruce

PaulZC commented 3 years ago

Hi Bruce, ODO support is coming in V2.0 of the library. V2.0 should be released around the middle of January. Best wishes, Paul

bvernham commented 3 years ago

PS, I just found out the m8u I am running FW version 1.0 so I do not know that does not have any influence on the two wire communication but I tried to run the HNR message example and it failed then I saw the note about needed the firmware 1.31. So looks like I need to upgrade...unfortunately with the holidays I have no idea how quickly UBLOX will respond. Have a good holiday season. Bruce

---------- Original Message ---------- From: Paul notifications@github.com To: sparkfun/SparkFun_Ublox_Arduino_Library SparkFun_Ublox_Arduino_Library@noreply.github.com Cc: bvernham bvernham@juno.com, Mention mention@noreply.github.com Subject: Re: [sparkfun/SparkFun_Ublox_Arduino_Library] Communication will no begin with DUE Wire1 (#163) Date: Wed, 23 Dec 2020 23:14:23 -0800

Hi Bruce, ODO support is coming in V2.0 of the library. V2.0 should be released around the middle of January. Best wishes, Paul — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

You Just Can't Leave a 1710 Violin in Your Car http://thirdpartyoffers.juno.com/TGL3131/5fe55f7493dd15f740e69st01vuc1 Trump's Move Stumps Georgia's Senators http://thirdpartyoffers.juno.com/TGL3131/5fe55f74b3d835f740e69st01vuc2 Employee Sues Tony Robbins Over COVID http://thirdpartyoffers.juno.com/TGL3131/5fe55f74d76825f740e69st01vuc3

PaulZC commented 3 years ago

Hi Bruce, Hope you had a good Christmas. You can update the NEO-M8U firmware yourself: Download u-center from here. Follow the instructions in section 8.1 of the user manual. You can download the firmware from this page (scroll down to Firmware Update and download the firmware image). You can find the Flash Information Structure (flash.xml) file in the u-center directory (C:\Program Files (x86)\u-blox\u-center_v20.10 if you are using Windows). Please let us know if this fixes your Wire1 issue. Best wishes, Paul

bvernham commented 3 years ago

Well, I did that and it did not go well. When I tired the new firmware updater it failed. When I used the legacy firmware upgrade it completed. I thought it was successful but the first sign of trouble was the PPS led on the board was stuck on all the time. Now I have no access to the IMU or is seems any UDR functionality. The firmware version page does not show any "UDR" like it did before. It seems like firmware was not the right firmware even thought is specifically says M8U. The first picture shows the PPS configuration even though the PPS LED is not blinking. The second picture is a snap shot of the firmware version which does not seem right. Any ideas? Is it possible to swap the board out with an M8U with the correct firmware because my project is dead in the water without the UDR and/or HNR messages responding. Essentially I now have a $70 brick that does not do what it is supposed to do. Thanks Bruce.

bvernham commented 3 years ago

OK, update...I disconnected the DUE so the firmware update went as expected and but now it will no communicate at all. Did the config get messed up? Can you send me a config file so I can get this working again? Because again it is stopping to progress of my project.

Again, all the other modules are working just fine and it is just the NEO-M8U BOB.

Thanks

Bruce

PaulZC commented 3 years ago

Hi Bruce,

The firmware image on the u-blox website works fine. I've just re-updated my M8U to make sure. I had the breakout connected to my Windows computer via USB-C, and had nothing attached to the Qwiic port.

image

image

u-blox modules are almost impossible to brick. I suggest you give it another try.

Best, Paul

bvernham commented 3 years ago

Yep, still stuck in the same place...EEPROM/BMP390L works great. NEO-M8U is a brick and will not communicate with either of my DUE's all of sudden. The interesting thing is if wire it wrong (SDA/SCL backwards) on the second DUE because of using jumper to qwiic instead of hard wired on the other board it fails communication immediately. If I wire it correctly there is a delay prior to getting the no communications error. I am starting to wonder if it has to do with the 1.5K pull up resistor which maybe the M8U does not like. I have a Nano 33 iot with a qwiic bob using 4.7K's and it seems to work OK with HNR. But the due uses smaller 1.5: resistors. Any thoughts? Maybe the EEPROM and the BMP390L have no issue with this but the M8U does. What other pulls ups have you had experience with?

PaulZC commented 3 years ago

Please read these notes on I2C pull-ups. Also see the Jumpers section of the hook-up guide. I routinely cut the I2C pull-up split pad jumpers on all my boards.

bvernham commented 3 years ago

Well, I removed the 1.5K resistors from the board and tried it with only using the internal M8U pull ups. Did not work.

Like the Nano QWIIC board, I also added 4.7K pull ups. Nothing.

Went back over to the EEPROM/BMP390. No problems.

I do not get it!

I don't understand how updating the firmware can tank all the I2C communications with the DUE. And I only have communication issues with the NEO-M8U. If I can not fix the problem my project is dead. I am worried that uart limitation would limit the capability of the system with the HRN messages.

Thoughts?

I need help to move forward on this.

Anything is greatly appreciated.

Thanks

Bruce

bvernham commented 3 years ago

I do not know if this helps but here is what the debug messages look like: SparkFun Ublox Example

Sending: CLS:CFG ID:RATE Len: 0x0 Payload: sendCommand: Waiting for ACK response checkUbloxI2C: Bytes available error:13666 checkUbloxI2C: Large packet of 13666 bytes received Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: no data and valid ACK after 2193 msec Ublox GPS not detected at default I2C address. Please check wiring. Freezing.

bvernham commented 3 years ago

On the Nano 33 IOT I get:SparkFun Ublox Example

Sending: CLS:CFG ID:RATE Len: 0x0 Payload: sendCommand: Waiting for ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 24 bytes Incoming: Size: 6 Received: CLS:CFG ID:RATE Len: 0x6 Payload: E8 3 1 0 1 0 packetCfg now valid packetCfg classAndIDmatch Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: valid data and valid ACK received after 111 msec

Sending: CLS:CFG ID:0x0 Len: 0x1 Payload: 0 sendCommand: Waiting for ACK response checkUbloxI2C: Reading 38 bytes Incoming: Size: 20 Received: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 3 0 0 0 0 0 packetCfg now valid packetCfg classAndIDmatch Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: valid data and valid ACK received after 15 msec

Sending: CLS:CFG ID:0x0 Len: 0x14 Payload: 0 0 0 0 84 0 0 0 0 0 0 0 7 0 1 0 0 0 0 0 sendCommand: Waiting for ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 10 bytes Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 0 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: no data and valid ACK after 106 msec

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 FF FF 0 0 0 0 0 0 sendCommand: Waiting for ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 10 bytes Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 9 packetCfg now valid packetAck now valid packetCfg classAndIDmatch packetAck classAndIDmatch waitForACKResponse: no data and valid ACK after 207 msec getPVT: Polling

Sending: CLS:NAV ID:PVT Len: 0x0 Payload: sendCommand: Waiting for No ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 100 bytes Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: 70 7A D4 E E4 7 C 1D 15 6 1C 3F D 0 0 0 2B EE FA FF 3 21 EA A 9D 2B 36 CE 58 43 42 19 A4 B6 3 0 56 3E 4 0 4F 10 0 0 83 16 0 0 FD FF FF FF 7 0 0 0 EB FF FF FF 7 0 0 0 5 FC 4 0 7F 1 0 0 8 5C 2B 0 C5 0 0 0 38 30 27 3C 5 FC 4 0 2B FD 46 0 packetCfg now valid packetCfg classAndIDmatch waitForNoACKResponse: valid data with CLS/ID match after 437 msec Lat: 423773016 Long: -835310691 (degrees * 10^-7) Alt: 243364 (mm) SIV: 10 getPVT: Polling

Sending: CLS:NAV ID:PVT Len: 0x0 Payload: sendCommand: Waiting for No ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 100 bytes Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: 58 7E D4 E E4 7 C 1D 15 6 1D 3F C 0 0 0 71 E6 FA FF 3 21 EA A AD 2B 36 CE 52 43 42 19 A9 B7 3 0 5B 3F 4 0 5 10 0 0 4B 16 0 0 C 0 0 0 6 0 0 0 DE FF FF FF D 0 0 0 5 FC 4 0 54 1 0 0 8 5C 2B 0 C5 0 0 0 38 30 27 3C 5 FC 4 0 2B FD 46 0 packetCfg now valid packetCfg classAndIDmatch waitForNoACKResponse: valid data with CLS/ID match after 334 msec Lat: 423773010 Long: -835310675 (degrees * 10^-7) Alt: 243625 (mm) SIV: 10 getPVT: Polling

Sending: CLS:NAV ID:PVT Len: 0x0 Payload: sendCommand: Waiting for No ACK response checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: OK, zero bytes available checkUbloxI2C: Reading 100 bytes Incoming: Size: 92 Received: CLS:NAV ID:PVT Len: 0x5C Payload: 40 82 D4 E E4 7 C 1D 15 6 1E 3F C 0 0 0 BC DE FA FF 3 21 EA B C2 2B 36 CE 44 43 42 19 84 B8 3 0 36 40 4 0 A0 F 0 0 D0 15 0 0 F9 FF FF FF E 0 0 0 F6 FF FF FF 10 0 0 0 5 FC 4 0 26 1 0 0 8 5C 2B 0 91 0 0 0 38 30 27 3C 5 FC 4 0 2B FD 46 0 packetCfg now valid packetCfg classAndIDmatch waitForNoACKResponse: valid data with CLS/ID match after 337 msec Lat: 423772996 Long: -835310654 (degrees * 10^-7) Alt: 243844 (mm) SIV: 11 getPVT: Polling

Any ideas?

bvernham commented 3 years ago

OK, so I went old school on this and did something simple. I ran an I2C scanner and low and behold:

I2C Scanner Scanning... I2C device found at address 0x42 ! done

Scanning... I2C device found at address 0x42 ! done

Scanning... I2C device found at address 0x42 ! done

Scanning... I2C device found at address 0x42 ! done

So it is not wiring and it is not a specific issue with my set up as like I said I have no issue communicating with the BMP390L and the SPARX External EEPROM and is specific to the initialization of the M8U.

Does this give any ideas?

Thanks

Bruce

PaulZC commented 3 years ago

Hi Bruce, Those debug messages from your NANO 33 IOT look completely normal. So this does not appear to be a problem with the library or your NEO-M8U. It appears to be a problem with Wire1 on your DUE only? I'm afraid I cannot help you with that. Over and out... Best wishes, Paul

bvernham commented 3 years ago

Paul it is not just Wire 1 now but Wire also. Why is it only the m8u which has an issue? No other i2c devices have a problem? This is either acquirk with the m8u or the library

PaulZC commented 3 years ago

Hi Bruce, No, it could easily be an issue with the I2C implementation on the DUE. It's rare, but we do see combinations of I2C devices and processors that just don't communicate the way they should. And, like I keep saying, I don't have a DUE so I cannot replicate your issue. There are some big changes coming in version 2.0 of the library, which include improved support for HNR on the NEO-M8U. I'm not confident, but it is possible that v2.0 could correct your issue. I'm working on v2.0 now (when I'm not talking to you that is! ;-) ) and hope to release it around the middle of January. Best wishes, Paul

bvernham commented 3 years ago

Well that is disappointing because the DUE has a lot of good features for my application. Native USB and two CAN channel. Many serial and so on. I am going to try to get some logic analyzer and O Scope screen snaps may help. I am not giving up on this one because this should be a very good package for vehicle data acquisition including both vehicle CAN bus data and physical performance data from the M8U. Thanks Bruce

---------- Original Message ---------- From: Paul notifications@github.com To: sparkfun/SparkFun_Ublox_Arduino_Library SparkFun_Ublox_Arduino_Library@noreply.github.com Cc: bvernham bvernham@juno.com, Mention mention@noreply.github.com Subject: Re: [sparkfun/SparkFun_Ublox_Arduino_Library] Communication will no begin with DUE Wire1 (#163) Date: Wed, 30 Dec 2020 05:29:23 -0800

Hi Bruce, No, it could easily be an issue with the I2C implementation on the DUE. It's rare, but we do see combinations of I2C devices and processors that just don't communicate the way they should. And, like I keep saying, I don't have a DUE so I cannot replicate your issue. There are some big changes coming in version 2.0 of the library, which include improved support for HNR on the NEO-M8U. I'm not confident, but it is possible that v2.0 could correct your issue. I'm working on v2.0 now (when I'm not talking to you that is! ;-) ) and hope to release it around the middle of January. Best wishes, Paul — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

Suspect's Girlfriend in 2019: He's 'Building Bombs in the RV' http://thirdpartyoffers.juno.com/TGL3131/5feca28559dc02285090cst04vuc1 Pence Rebuffs 'Extreme Call' From GOP Congressman http://thirdpartyoffers.juno.com/TGL3131/5feca2857d1142285090cst04vuc2 More Bad News for Breonna Taylor Bust http://thirdpartyoffers.juno.com/TGL3131/5feca285a22862285090cst04vuc3

PaulZC commented 3 years ago

Hi Bruce (@bvernham), I've included some improvements to .begin and .isConnected in version 1.8.10 of the library. You should see the new version in the Arduino IDE Library Manager from tomorrow. I don't think this will fix your DUE issue, but you never know! All the best for the New Year, Paul

bvernham commented 3 years ago

Paul, 1.8.10 did not help.

I took some o scope and LA data today. I set up the begin in a continuous loop for both the DUE and the Nano DUE Data: O scope looks cleaner than the Nano

Due DUE image

Nano Data: Nano data seems to have an additional write Nano 33 IOT Nano QWIIC BOB Repeat Begin Nano 33 IOT Repeat Begin 1 Nano 33 IOT Repeat Begin 2 image

Does this give any hints?

PaulZC commented 3 years ago

Hi Bruce,

Happy 2021!

This is seriously weird...

Both systems seem to be using 100kHz - which is good.

The NANO data looks completely normal. The write to 0xFF let's the u-blox module know that we want to read I2C data from register FF. B5 62 06 08 06 00 E8 03 01 00 01 00 01 39 is the NAV RATE message that we use to check that the module is talking. B5 62 05 01 02 00 06 08 16 3F is the ACK for the NAV RATE poll. Then the NANO starts to write RATE data back to the module. That's all normal.

The DUE data is just showing "data not ready" (FF) continuously:

image

I have no idea why...

Can you send me a photo of the connections between the NEO-M8U and the DUE?

Best, Paul

bvernham commented 3 years ago

IMG_20210101_080050206 HNY right back! I sure hope it is a heck of a lot better year for everyone then the last! Anyways it is the same wiring used have no issues with the BMP390L or the SPARX EERPOM.

I have also used a Sparkfun adapter cable from male dupont pins to the QWIIC connector. None of it works.

Thanks for the help.

Bruce

bvernham commented 3 years ago

One other question. I am running off serial 3 on the DUE just fine (go figure) running the dead reckoning HNR example 6 and I notice the accel data is zero always. Is this because the sensor are not calibrated yet?

I have not put it in the vehicle yet because was fighting the communication issue.

Should I expect to see anything?

Thanks

Bruce

PaulZC commented 3 years ago

Hi Bruce, Thanks for the photo. So, which pins are you connecting to on the DUE? And where are you drawing power from? Re. your other question: we're getting a bit off-topic here. But, yes, that's my understanding, you don't get the full sensor data until calibration is complete. Best wishes, Paul

bvernham commented 3 years ago

I put the modules on a perf board which is mounted to a mega BOB.

I have 4 pin header on the BOB for Wire, Wire1 and now Serial3.

I connected one end of a QWIIC pigtail to a 4 pin dupont connector

I added a 3.3v bus powered by the due with 10 uf bypass caps on both ends. All the QWIIC modules are powered off the same buss.

When I connected the Nano 33 IOT it was connected to the QWIIC BOB.

As the OSCOPE shows, the DUE seems to have a little cleaner power.

Thanks

Bruce

PaulZC commented 3 years ago

Hi Bruce, That all sounds perfectly OK. Sorry - I'm completely stumped and don't know what else to suggest... I really hope you get to the bottom of this. Very best wishes, Paul

bvernham commented 3 years ago

Well I have put this on the Arduino (considering it is a Arduino board) and on ublox but so far this and Sparfun forum are the only ones to respond. Thanks

---------- Original Message ---------- From: Paul notifications@github.com To: sparkfun/SparkFun_Ublox_Arduino_Library SparkFun_Ublox_Arduino_Library@noreply.github.com Cc: bvernham bvernham@juno.com, Mention mention@noreply.github.com Subject: Re: [sparkfun/SparkFun_Ublox_Arduino_Library] Communication will no begin with DUE Wire1 (#163) Date: Sat, 02 Jan 2021 09:55:38 -0800

Hi Bruce, That all sounds perfectly OK. Sorry - I'm completely stumped and don't know what else to suggest... I really hope you get to the bottom of this. Very best wishes, Paul — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more

McConnell Decries 'Radical Tantrum' http://thirdpartyoffers.juno.com/TGL3131/5ff109774b26a9770823st01vuc1 Electoral Fight Adds GOP Votes http://thirdpartyoffers.juno.com/TGL3131/5ff109776edf59770823st01vuc2 Trump Skips His NYE Party at Mar-a-Lago http://thirdpartyoffers.juno.com/TGL3131/5ff109779267c9770823st01vuc3