Ok @splee, I would never have gotten there. Thanks for the additional and useful information.
Be patient but could you tell me, as you indicated for LG290P, the position of the levers and their function for LC29EA.
thanks for everything!
AF
@falajons Itâs the same. I got the schematic from @bamarcant, and it was actually for the LC29 board, but both boards are the same basic design. I did verify on my LG290P board that they work that wayâŚ
ok @splee, thank you very much. Yes, it is true that lc29hea and lg290p are similar in terms of hardware and format, however lc29hea does not have three uarts but only two and for this reason I took the liberty of asking you about this module too. So if I use lc29hea with uart-usb I have to put all the two toggles up while if I use the uart with pins I have to put all the two toggles down!??
Yes, as you wrote, my problems as a uart are also a consequence of these settings. thanks again. AF
Hi Tom, witch ide do U use 2.xx or 1.8x for compileâŚcan U post a Uart2_BT_BLE_Brigde.ino.merged.bin
I cannot compile it anymore less errorsâŚ
Did U resolve the uart problem posted before in other tread?
Vielen Danke
Marco
It compiles fine with IDE 2.3.2. However, Iâm having trouble getting it to work reliably. At 115200bps, it will connect, then almost immediately disconnect when it starts transmitting data. Often it will reset too. Lowering the speed down to 38400 allows it to connect and actually send data to SW Maps. But when I turn on NTRIP, it will more often than not crash again.
I will spend some time trying to get this to work as I really do want a BLE bridgeâŚ
The description of of 3 uarts for the LG290P and 2 for the LC29H is slightly misleading as one of the uarts is just for I2C protocol, not async serial. So that leaves two useable async serial ports of the LG290P board, and just one for the LC29H.
Yes
Here the zip with the bin files for Uart2_BT_BLE_Bridge.
Please try it.
Uart2_BT_BLE_Bridge_bins.zip (706.6 KB)
1 Like
Danke fĂźr deine Beitrag.
I will test itâŚ
But then you solved the uart issue on the lg290p with 3.3v cc?
No, I did not solve the issue on the LG290P with 3,3V. Only know now, it can not run with 3.3V; otherwise the chip will die sooner or later.
Hi Tom You were right to let it be knownâŚa chip with 79 pins should not fit on a board made for the 24 classics pin.
However I also fried two on the above board (designed for ubxâ chips that have the same pins) with the chip that I burned.In yellow the traces I removed on the second but still fritto.
Grazie ancora e ti saluto
Thatâs the problem: The lack of information or wrong information. Waste a lot of time and even money to find correct information.
1 Like
So, I need to qualify this. I am having this problem when using it in BLE mode with an iOS device. When using it with an Android device in BT mode, it works fine up to 460800bps. But strangely enough, on Android, the BT name still shows up as BLE_RTK even though it is supposed to be BT_RTK.
I will keep plugging awayâŚ
Ok, finally with @spleeâs suggestions I managed to receive data via esp32 wroom (with the sketch that uses classic bluetooth - 460800 baud rate). I connect easily (I use an Android mobile phone) and receive the position data: I arrive at the float position then at a certain point I see part of the satellites disappear and then reappear and this goes on forever. From float I regress to dgps or single. In short, everything seems to be going haywire (sw maps skipplot). What could it be???
By the way, with LG290P I confirm that if the UART is not powered with 5V nothing works. I connected the 5V pin of the esp32 and the module didnât bat an eyelid!
thanks again @splee.
I would add that they desoldered the lc29hea and now it works normally via USB.
I was lucky I didnât make the omelette! Greetings
AF
@falajons So it was those silly switch settings that tripped you up! They are poorly marked and there are really no documentation with the modules. Good thing you didnât fry your module (or make an omelette, as the translator says)⌠
.
On your flaky connections, stand by. I am currently doing some investigations and am finding out some interesting stuff. I donât want to say it before I have definitive information. but as soon as I know for sure, I will update.
@splee: in my opinion my failures are due to the power supply problem because I had tried all possible combinations with the sticks.
However, I too have wasted hours doing experiments and attempts in the dark.
Here, rather than Quectelâs, it is perhaps a problem of whoever assembled the GPS card (mozihao).
The âmozihaoâ manual would also be needed in addition to the quectel one.
Thanks so much for your assistance.
I await the results of your tests with eagerness and curiosity!
Greetings
@falajons Your comments above about the satellites going in and out got me thinking. I was seeing this too but because I was chasing other issues before, I did not pay too much attention to that. Now that I solved my other problem, Iâve come back to this, and long story short, the esp32 we are using as a uart BT bridge cannot keep up at high speeds and is probably dropping packets, hence the satellites fluctuating. Itâs all because the Quectel module defaults to 460800, so everyone wants to just use the default, with one less thing to configure. But our esp32 bridge cannot handle it. I never noticed this problem before because I was running the bridge at a slower rate with my F9P module.
So, I tested this with 3 BT bridge solutions:
- My simple one, with software uart
- The HW uart one that @bamarcant posted
- The one from @tomrm
All programs performed best at 115200 bps. If you drop it to 57600, it actually gets worse, so 57600 may be too slow to keep up with the data. When you start increasing the rate to 230k and 460k, all programs start to drop messages, in varying degrees. You can still get position and even float and fix sometimes, but if you look at the Satellites in View and Satellites in Use numbers in Skyplot, they fluctuate wildly. But itâs not the way to run it, with obvious missing data.
So, the winner is the HW uart version that Marco sent out. At 115200 bps, it is rock solid, with the satellites only varying by one or two, just like in the QGNSS or Ucenter screen. However, even with the HW uart, when you try the next step up. 230k, you start to see fluctuations in the satellites, more than I care to accept.
The other two programs both use sw uart, so although the are ok at 115200 (not as rock solid as the HW one) and even higher speeds, they both drop more packets than I like, so Iâm going to stick with the HW one for now.
Let me add that this is all anecdotal. I donât have the equipment to actually see if packets are being dropped at those speeds. But given that everything else is the same, GPS antenna, GPS module, etc, logic would indicate that data is being lost somehow in the esp32. I also used my F9P module instead of the LG290P since it was the most convenient, but it should hold for the LG290P. I can check that tomorrow.
So, for best, most stable, loss free performance, use a HW uart bridge firmware. Thanks @bamarcant
Try my optimized bridge, which should hopefully allow higher baudrates.
2 Likes
Hi Tomrm and thanks for the sketch.
I have to say though that my Arduino IDE 2.3.3. he doesnât want to âdigestâ it.
It gives me the error you see in the image.
How do I solve it.
Thanks again Tomrm!
AF
