I have successfully used the Sparkfun U-blox GNSS v3 library to create an NTRIP device on an ESP32 using example 17. I am trying to do the same with a Boron using the LTE connection directly. The example creates a wifi object but there is not a wifi library available in the Particle Library repository. I also cannot edit the libraries, which I think is intentional.
The Particle NTRIP library only has provision to connect and get the mountpoint list. There is no .write or .print method to send NMEA GGA sentences.
Any advice on how to proceed would be appreciated. Thanks!
The main goal is to use the Boron as a standalone NTRIP client to use with either u-blox or an Oxford RT.
This isn't a complete answer to your question, however:
However example 17 in that library is Geofence, so I think you're using a different library, but I didn't see an obvious answer to which one.
In any case, that's how you modify a library.
To clarify Example 17 in the ZED-9FP folder. I will look into the Particle Workbench. I have been using the online IDE.
Also, the Particle version of the Sparkfun u-blox library has just boiler plate code for the main .cpp and .h files. Would be nice is someone could fix that and convert the wifi references to work with LTE.
The community libraries are contributed by the community and are difficult to keep up-to-date as people come and go. It's easier just to grab the source from Github and use it directly in Workbench.
That example 17 makes more sense and it should mostly be replacing WiFiClient with TCPClient and removing the SSID stuff and it may just work.
1 Like
OK, I have installed TlsTcpClient library. It is a little different from Wifi.h but I have fixed most of the invalid references and type defs. Still fixing compile errors. I am new to Visual Studio Code. Main experience is with Arduino IDE.
Just giving an update, and that I still have not resolved this project. I intend to share my success if I do get there!
I finally got it to compile! However, I keep getting Time Out errors when trying to flash locally. Exit code: 2.
Another question. Does having #Include Arduino.h (in some of the libraries) cause any problems? Should I replace them with Particle.h?
Arduino.h includes Particle.h, but also sets some things for added Arduino compatibility. If it compiles with Particle.h you should use that instead.
Which flash option are you using? Particle: Flash application (local)?
I have tried both, but would prefer to use the local one. I know with Arduino you have to set the Serial Port. I do not see that option with this, only they device type and Name. Is that correct or am I missing something?
Request timeout
make[1]: *** [C:/Users/TRC_Doug/.particle/toolchains/buildscripts/1.16.0/Makefile:177: flash-app] Error 1
make: *** [C:/Users/TRC_Doug/.particle/toolchains/buildscripts/1.16.0/Makefile:120: flash-user] Error 2
You do not need to set the serial port. Is the device going into DFU mode (blinking yellow)? I suspect not.
You could also try using Particle: Configure Project for device. Select the device type and version, and when asked for the device name or ID, hit Escape. This will use whatever device you have plugged in by USB instead. It may be trying to open the wrong device.
I clicked "Configure for device", selected Boron, then OS6.1.1, then escape when it asked for device name.
LED is not changing from breathing cyan. I had Arduino USB device plugged in before, but just tried without it... same result.
Any suggestions? Is there a button on the device I should press at a certain time? I was able to load a simple sketch from the online IDE before.
I thought of creating a new simple project in Visual Code just to confirm the process.
It's possible that the firmware on the device is preventing it from being flashed by USB. Hold down the MODE button and tap RESET. Continue to hold down MODE until the LED is blinking yellow and release.
Thanks Rick! IT FLASHED! Now on to troubleshooting, and making sure it actually works! Unfortunately I am on site at work and don't have my ublox.
It rebooted and is fast flashing green. OK, never mind. It just acquired signal and is breathing cyan again as I typed this out.
OK, so I am stumped again. As soon as it tries to connect to the NTRIP Server, the LED flashed RED and reboots. Something is obviously not happy.
Earlier I said I was using example 17 from the ZED-9FP folder, but it is actually 16. I did you what you suggested and replaced the Wifi library with TlsTcpClient. I had a few data types mismatches, but overall was straight forward.
I believe this is the method being called when it crashes:
TlsTcpClient::connect(uint8_t *ip, uint16_t port)
Here is first half of the function being called after waiting for a keypress in the Loop:
void beginClient()
{
TlsTcpClient ntripClient;
long rtcmCount = 0;
Serial.println(F("Subscribing to Caster. Press key to stop"));
delay(20); //Wait for any serial to arrive
while (Serial.available())
Serial.read(); //Flush
while (Serial.available() == 0)
{
myGNSS.checkUblox();
//Connect if we are not already. Limit to 5s between attempts.
if (ntripClient.isConnected() == false)
{
Serial.print(F("Opening socket to "));
Serial.println(strCasterHost);
delay(50);
if (ntripClient.connect(casterHost, casterPort) == false) //Attempt connection
{
Serial.println(F("Connection to caster failed"));
return;
}
else
{
It prints "Subscribing to Caster. Press key to stop". then locks up. One time the serial monitor printed: Opening Socket to 000.000.000.000 (but actual IP to caster) but usually it just locks up.
Any advice?
The red blinks form a SOS pattern which may help, but really it's probably a problem with a parameter passed to something, or a bug in the library.
However almost certainly the TlsTcpClient object should not be declared within the function because it will be deleted when the function exits, which is probably not what you want.
Make sure you have initialized the TLS TCP client properly; I think you need to initialize some things like the certificate chain before you can use it.
What I would probably do is start out as simple as possible with just a program that makes a TLS connection.
1 Like
OK, that is a good idea. I need a better understanding of how this all works. It is a bit outside my wheelhouse, but I am willing to learn and know just enough to be dangerous. Thank you for your timely responses! I will report back when I make more progress.
With the help of Grok, I have made some good progress. Turns out that there is an internal TCPClient library, which is much closer to WiFi (previously using TlsTcpClient). I switched to that and it no longer flashes red and reboots. The only weird thing is that Serial Print did not like casterHost variable type, so I remove the "const" from the variable type in secrets.h not sure why const char was being interpreted as unsigned.
invalid conversion from 'uint8_t*' {aka 'unsigned char*'} to 'char' [-fpermissive]
I am now using Example 17 again from the ZED-9FP folder of the Sparkfun_u-blox_GNSS v3 library. Only modifications are TCPClient replacing WiFiClient and commented out connecting to wifi section.
The problem now is, when opening the socket to the host, it fails. I am not sure how to find the TCPClient.h to compare it to WiFiClient. It works on the ESP32... so I know that the IP address is correct. I also tried a different NTRIP Server host. Same result.
TCPClient is documented here.
If you want to see the source to the .h file, it is here.
1 Like
Thank you for the reference. I FOUND THE SOLUTION!!!! I changed to the client.connect(server, port) overload as a byte for the server IP. THAT WORKED!!!!!!!!! I added to secrets.h:
byte server[] = {xxx, xx, xxx, xxx}; //actual code has numbers where x's are
not sure why the IP address as a char string didn't work., but the byte array does!
Thank you again for your assistance and timely responses! Now I just need to not overuse my data while testing.
1 Like