Skip to content
This repository was archived by the owner on Jan 28, 2021. It is now read-only.

esp32 and m8u dead reckoning not working #120

Closed
joeholdsworth opened this issue Aug 11, 2020 · 3 comments · Fixed by #155
Closed

esp32 and m8u dead reckoning not working #120

joeholdsworth opened this issue Aug 11, 2020 · 3 comments · Fixed by #155
Labels
fixed Issue is fixed

Comments

@joeholdsworth
Copy link

Subject of the issue

in i2c mode the m8u dead reckoning never calibrates, if I use it in uart mode with ublox center it does. Some I2C requests occasionally do not work.

Your workbench

  • What development board or microcontroller are you using - ESP32
  • What version of hardware or breakout board are you using - sparkfun neo m8u
  • How is the breakout board wired to your microcontroller - I2C lines, 3.3v supply capable of 300mA
  • How is everything being powered - via an LDO 3.3v 300mA reg
  • Are there any additional details that may help us help you - id like to perform a check that the DR mode is enabled, is there a command for this?

Steps to reproduce

Tell us how to reproduce this issue. Please post stripped down example code demonstrating your issue.

I'm using the sparkfun examples provided, specifically the DR fusion calibration status, it never achieves calibration,if I perform the same vehicle maneuvers in uart mode and use the esp32 as a serial to usb bridge with the ublox center, it does.

Expected behavior

fusion calibration staus should indicate calibrated

Actual behavior

unit never calibrates

@Daedaliss10
Copy link

Daedaliss10 commented Aug 14, 2020

removing comment and starting separate issue

@PaulZC
Copy link
Collaborator

PaulZC commented Oct 5, 2020

Hi @joeholdsworth ,

Apologies for the very slow reply - this fell off my radar...

Are you having the same issue as this one?

Best wishes,

Paul

@PaulZC
Copy link
Collaborator

PaulZC commented Nov 30, 2020

Hi @joeholdsworth ,
Thank you for your patience!
It has taken a while, but I think we have found the root cause of this issue. There was a gremlin in the code that meant the calibration status wasn't being extracted correctly. The correction is here:
04d8f4a#diff-56e995c8ccf5d6b3bc269a8eaf038164594becf0f1c2df99616a0cd4f803c028R4098
The changes are still in the release_candidate branch, but I hope to be able to merge them into a new release in a day or two.
Thanks again for reporting this.
Best wishes,
Paul

@PaulZC PaulZC added the fixed Issue is fixed label Nov 30, 2020
@PaulZC PaulZC linked a pull request Dec 1, 2020 that will close this issue
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
fixed Issue is fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants