Closed fxbisto closed 5 years ago
Hi, hardware malfunction is unlikely. It is not even pull up, because this is an strictly output pin, it is not bi-directional, so does not go in receive (high-Z mode), so pull-ups are not needed. It always drives the pin as output high or low.
The most likely explanation is that somehow the rx switched to SBUS mode. SBUS is inverted so the idle level is 0. I really have no idea how exactly this might have happened (if that's really the case). Depending on your transmitter it could be possible to select IBUS/SBUS from the transmitter itself. For A8S receiver I have heard that holding the bind button for 2 seconds switches between IBUS and SBUS. Maybe that's supported by 8A also, since they use almost the same firmware. Maybe while you were handling your quad the rx got pressed against the frame and the button was activated?
Depending on the state of your setup it might be faster to try soldering the signal to a sbus pad of the fc and set bf for the sbus uart, and see if it works.
Thanks for the response. That's interesting regarding the SBUS option, I am aware that these 8A's say they support SBUS out but haven't ever actually managed to activate it in the past. With the ia6B and several others you can change it from the "Rx Setup" menu in the i6, but that doesn't affect this one.
Seems like the most plausible option at the moment, I will attempt this when I get home after work.
I'm encouraged by the fact you feel h/w failure is unlikely, although confused that a couple of bytes were off in the firmware, maybe they are some kind of config bytes?
Cheers
Bytes were different compared between which two firmwares?
Between the STM on the 8A and the 1st June 8A firmware on my pc. I re-downloaded it to rule out the possibility my local file that was wrong, but it was fine.
8A and A8S seem to store all their mutable data in EEPROM, so flash should not change by itself while on the chip. At least I think so.
For IA6B and others it's different. They also use EEPROM to store various stuff but they store the transmitter ID and the sequence for frequency hopping in flash. So on re-bind these bytes change.
@Cleric-K you were right on the money; Holding in the bind button for 2 seconds does indeed switch between iBus and SBUS. Sometimes the most obvious solution is the correct one! I wonder how many 8A's have been thrown out as faulty for this very reason? Either way, a massive thanks to you :)
Perfect! I'm glad that this has worked out. Happy flying :)
As title states; iBus signal has for some reason lost it's pull-up, so the data is invalid. I've had this receiver working for about a month but only used it maybe 25 times, it's in a micro that I fly in the back garden when I get a chance. Yesterday after 2 packs I plugged in the 3rd as normal (No crash between packs) but the craft wouldn't arm. Tx is bound fine, solid red light on the Rx, all wiring intact. I swapped another using the same wires as they're cut to length, all working. The faulty Rx appears to work fine but can;t communicate with the FC.
**Edit - I have re-flashed firmware because it failed verification on a few groups of bytes, although no improvement. Seems fairly likely to be h/w related.
I haven't tried re-flashing the firmware yet. Does ### anyone know if pull-up activated in the STM or whether it's an external resistor? Could a re-flash fix this if so? I know a flipped bit is super unlikely, and I'm leaning towards STM failure.Perhaps as this one is only for the back yard I might try adding a 3v3 pull-up to the data line - thoughts?Here's some scope traces to show the issue a bit clearer:
Malfunctioning 8A:
Functioning iBus link:
If it turns out this is just a hardware failure then please accept my apologies!
Cheers