updating to .12 again
Hi Eric,
I just checked and " #define Data_Streams_Enabled // Requests data streams from FC." was already enabled.
Just a note that not all telemetry is drying up. I still get all other data on Yaapu script except GPS info. And I get GPS info as well at the startup but GPS info disappears right after my Arduplane GPS fix changes from 3D Fix to 3D dgps.
Everything else is working. I get HUD display on yaapu, I get messages on yaapu but its just the GPS stops working after the change in GPS fix. BUT when yaapu script is announcing “No GPS” I still can see valid GPS co-ordinates on Heltec OLED.
Is there a difference whether I choose esp8266 variant 2 or 3?
Heltec wifi kit is what I have
update:
2.67.12 flashed again. Im able to connect to Access point, mission planner connected via UDP using 14555, all parameters downloaded. BUt the problem is when I turn on my radio and yaapu connects, the wifi connection drops…but yaapu remains connected
did you get the same observation @ninja_zx11 ?
to verify, i tried rolling back to 2.67.5 again, it seems that the 2.67.5 firmware is more stable for me. wifi connection doesnt disconnect frequently when yaapu connects.
@Erwin: Ok, I’m looking at v 2.67.12, to keep it simple for me.
I want to take a closer look at what happens to GPS fix when it changes to (ap24_fixtype==4) Log.print(" DGPS/SBAS aided"); I can’t simulate your circumstances here right now, so I will need your help please.
Would you mind flashing and running v2.67.12 again, but with these debug lines activated:
#define Mav_Debug_GPS_Raw
#define Mav_Debug_GPS_Int
#define Frs_Debug_LatLon
and post the serial monitor log.
Alternatively , post a TLog.
Not sure why you should lose wifi connectivity when you switch on the transmitter. You are transmitting on the same 2.4GHz band as the wifi, so if the antennas are in close proximity there could be a problem there. I can’t immediately recall your radio details.
interesting, the antenna are quite close to the heltec, possibly the reason why it’s dropping… but i guess that still doesnt explain why on 2.67.5, it looks much stable
@Eric_Stockenstrom I have sent you my Tlog as a message. I will try re-flashing with debug lines ON tonight when I get home. Thanks for checking Eric.
@epquilloy I tested 2.67.12 as a Relay on my Heltec . WIFI connection and S port telemetry were both stable. No issue of disconnecting. Parameter download was kind of slow but connection was stable.
Only issue I am having is loosing GPS info on Yaapu as soon as I get dgps fix on my plane. Eric is working on the issue.
thanks! i guess it could be a hardware issue…
Hi – I am migrating to using a relay with Draginlink using a Heltec Webit 32 board that has worked well stuck to the Dragonlink mounted on my Radio.
Using VS Code and Plotform.io I just used the platform.io folder on Github. Frsky telemetry had to be set to the Auto option before the Yaapu script could receive S Port. That is a known issue and trivial – I would add it to the config.h comments.
My biggest problem is there is no Mavlink heartbeats on UDP when I connect to the wifi network. This also seems to be an issue with others as well. I notice the Paltform.io folder has 2.67.9 as the lastest on Github.
Should I just be using 2.67.15 now?
Also, and this is not very important I have noticed on many versions the OLED display starts out crisp but at some point it just becomes a little corrupted. You can sort of read if you know what it is supposed to say. Curious, has anyone else noticed this and is there a fix?
And to answer above – using 2.67.15 fixed the wifi connectivity to Mission Planner.
Hey Marc
Good to hear from you.
Thanks for the feedback. Do you mean the small OLED display? The 0.96 inch one? The bigger 3 or 4 inch one has much more functionality.
I’m quite deeply into some other stuff, so these projects have been a little neglected, but I’ll update the PIO version and take a look at the display. I know what’s happening there, it just takes a bit of time to watch and resolve.
P.S. We switched the UDP port numbers around for a particular application, and then left them switched for a version or two. 
That might explain the Mission Planner issue.
“many versions the OLED display starts out crisp but at some point it just becomes a little corrupted”
Marc, I tried to reproduce this issue but without success. Could you possibly send me picture?
This could simply be an I2C bus corruption on the board.
V2.67.16 ported to PIO on GitHub
Hi Eric,
It seems like there is one small issue with the batt current readings in the newer versions. I found out that if my plane is consuming 2 amps then the yaapu is displaying .2 amps. So one decimal place difference. Batt current readings are correct on version 2.62.8 I tested. I am running relay setup.
I tested few newer versions and this issue is present in all of them. Not sure where is the problem.
Here is my SPort signal waveform between Heltec ESP32 and R-XSR receiver ( Un-Inverted smart port pad) using high speed Schottky diode.It looks like pulses from either Rx or Tx ( not sure) are not going to absolute Zero volts. I probed this signal at the uninverted pad of R-XSR. Is it okay? Asking because some times I get message text corruptions.
Hi ninja_zx11 - Am
Thanks for the feedback on the battery current from version 2.62.8 onwards. Are you sure you don’t mean v2.67.8? I will look at that.
Yes, the ONE-WIRE protocol has 3 levels, but what is strange is one signal is apparently inverted (idle low)), and the other is not. Check that both the RX and the ESP32 signal have the same polarity.
Hi Eric,
Yes I meant 2.62.8. I went back to 2.62.8 and my batt current readings are good again. I also noticed that the readings rise slowly with a delay if i turn my motor on but moves back instantly after switching the motor off.
Regarding the signal wave form, I think signal is idling high ( at the uninverted pad of r-xsr Rx). I captured both incoming and outgoing.I am no expert but looks like both are idling high at 3.3volts and one is coming down to 0 volts and second is coming down to 1.2volts only.