Wi-Fi stability issues when GPS module connected

[ljozsa]

Hi,

I'm suffering with random Wi-Fi AP crashes when GPS module is connected. The Wi-Fi hotspot just dies within a minute or so. I don't see anything suspicious on console. I see data flowing over Bluetooth so the CPU is alive. When GPS is disconnected Wi-Fi connection seems to be much more stable.

Thanks,
L.

[lyusupov]

Stand by. Advisory will follow.

[lyusupov]

Some of the SoftRF builders had reported that they are affected by this (or similar) issue, some - did not report...

Abstract: it is known fact that current Wi-Fi stack on ESP8266 is not "interrupt friendly".
This is an issue of Espressif 8266 SDK + Core (+SoftwareSerial library)

I have 4 workarounds and solutions against this to reduce the impact of this issue on the SoftRF project.
I will not give all of them right now. Let's start from initial, "least actions" approach:

Use any USB-to-RS232 adapter and re-configure your GNSS module to supply minimum required NMEA messages. For SoftRF it is sufficient to input $GxRMC and $GxGGA only.
For a reference NMEA (+"Legacy") output - use my logs mentioned in this ticket: #1

The name of the configuration utility for uBlox-8 based BN-880 modules (referenced in Standalone's BOM ) is uCenter. Use google for the configuration instructions. Don't forget to strore settings into GNSS's NVRAM.

Report if you are still suffering from the issue when you are done.

The ticket is re-assigned back to you.

[ljozsa]

Thanks for your suggestion. I have reconfigured the GPS module as you proposed and the stability is a little bit better in terms of how long's Wi-Fi alive. The hotspot no longer disappear while other communication goes on but I'm observing much higher frequency of CPU reboots. It keeps rebooting roughly every 10 minutes if the client is associated with the AP. It seems to be more stable without client connection. For the reference I'm using the V.KEL VK2828U7G5LF GPS module but this should not matter as it's the same uBlox-8 hardware.

[lyusupov]

Check your NodeMCU and PCB soldering quality. Any small invisible "solder bridge" may cause increased current drain which, reported, leads to reduced stability of the NodeMCU board. Try to use another instance of the NodeMCU.

Please, provide:

• boot log taken over USB cable
• screenshot of settings
• screenshot of status

Typical in-flight use case of Standalone is:

• minimal use of Wi-Fi: few, rare sessions for configuration purpose only
• watch LED ring for warnings
• feed FLARM NMEA data wirelessly over Bluetooth for a Flight Computer

Brief list of all known workarounds and solutions against "ESP8266 Soft AP issue":

1. Wireless client mode
2. AP, Software serial, reduced NMEA input, increased baud rate
3. AP, Hardware serial
4. ESP32

You are currently using partial 2) workaround.
Solutions/workarounds 1)-3) - all of them have some compromises.

The only currently known "no compromise" solution is to migrate onto ESP32.
But it needs more builder's actions and time spent.
So if you need "no compromises" - we may close this ticket and you proceed into transition onto ESP32.
Expect to wait until April when I'll publish "gerber" files of adapter for ESP32 to sit into NodeMCU's socket.

U7 in the product name VK2828U7G5LF means - it is uBlox-7 based. You may test it by doing UBX -> MON -> VER in u-Center.

True uBlox-8 module is VK2828U8G5LF ( to be more accurate: UBX-8030 chip based - since none of these Chinese GNSS units is having genuine uBlox NEO module been soldered)
This is an example of such module: https://www.aliexpress.com/store/product/VK2828U8G5LF-BeiDou-GPS-GLONASS-Module-UBLOX-NEO-M8N-for-Flight-Control-Model-Aircraft-FACTORY-PRICE-OEM/2885123_32799450272.html

[ljozsa]

So after changing the NodeMCU board system doesn't reboot anymore, that's good. So it seems there was some hardware issue, I'll inspect the board for solder bridges. The WiFi AP crashes after longer time than before, so hypothesis with interrupt problems seems to be correct.

I'd like to try option 1). Does it require recompilation of the source code? Or is it possible to set it up somehow?

It's true that once I setup the module over WiFi for the first time there wouldn't be much use cases for the WiFi so it's not so critical. I'm using it more this time since I'm playing with the various options.

BTW I tried to switch the protocol to Legacy and my OGN receiver doesn't see it. I'm quite far away from it, so it's possible that if the OGNTP uses a different modulation, the problem can be too weak signal. Did I understand it correctly that Legacy protocol should be compatible with current FLARM's so the FLARM should see it? I haven't got a chance yet to try it against FLARM.

I'd like to also ask about FANET - is this compatible with OGN receiver? The cool feature that I like there is retransmission of the packets by participating nodes.

Thanks for info about chipsets in GPS module. Yep, you're right it's uBlox-7.

Also, please note that if the troubleshooting is too time consuming, I'd rather wait for ESP32 solution and not waste your time on ESP8266 that you'll deprecate soon.

[lyusupov]

I'd like to try option 1). Does it require recompilation of the source code?

1. follow this guidance first: https://github.com/lyusupov/SoftRF/tree/master/software/firmware/source
2. then edit https://github.com/lyusupov/SoftRF/blob/master/software/firmware/source/SoftRF/SoftRF.h
   with your SSID/PSK and re-build

BTW I tried to switch the protocol to Legacy and my OGN receiver doesn't see it.

Update your firmware onto RC2. Release notes: https://github.com/lyusupov/SoftRF/releases

I'd like to also ask about FANET - is this compatible with OGN receiver?

I think - no, but you'd better ask OGN guys.

The cool feature that I like there is retransmission of the packets by participating nodes.

OGN tracker (OGNTP) does also have "retransmission".
I think it is more "marketing feature" than reality because, when:

• following "1% duty cycle rule" on 868 MHz band and
• 1 packet per second transmit rate and
• "time in the air" of every protocol

there is no a timeslot to legally transmit anything except own position.
OGN guys are using freq. hopping and interleaving to achieve retransmission,
but anyway it likely works good only for a low-scale (1-3 units flying around)

And significant remark on compatibility of SoftRF with other protocols:
It is necessary for a reader to distinguish the difference between statement "compatible"
and statement "fully compatible".
SoftRF implements only a "minimum" or "close to minimum" protocol support.
No "bells and whistles" so far.

on ESP8266 that you'll deprecate soon.

No. There are reasons to maintain both ESP8266 and ESP32 platforms at least
until the end of year 2018.

[ljozsa]

Linar, thanks a lot for all your help and explanations. I tried to compile the code myself and everything's work as expected. I think we're good to close this issue.

I'm close to completion of 5 trackers that will be put into our aeroclub's gliders so we'll see how it goes in practice.

[lyusupov]

Recent improvements in this experimental branch of SoftwareSerial library give us a chance for this issue to become at least partially fixed.
Coming soon...

[lyusupov]

Fixed in 9201a99

[lyusupov]

This issue has become rare but still exists (on NodeMCU/SoftAP only).