Hey folks. So for a beginner DIY fixed-wing flight controller, I am trying to incorporate servo values from an external receiver via SBUS [by FrSky (0-> Low, 1-> High; contrary to the standard SBUS by Futaba)] into my software.
I found a good amount of code for the sum frame decoding, but appear to not receive any UART communication at all from the receiver.
A UART RX Callback function generates an interrupt whenever there's a new frame received. The function is supposed to write a message via another UART to my Putty-terminal (which works fine), upon calling.
Further into it, the SBUS frame gets torn apart and the individual channel values generated - but I'm not even at this stage, and by the looks of it, it should work fine. My code:
/* Private user code ---------------------------------------------------------*/
/* USER CODE BEGIN 0 */
uint16_t failsafe_status;
uint8_t buf[25];
uint16_t CH[18];
int lenght=0;
uint16_t USB_Send_Data[]={0};
char msg[25];
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart1)
{
sprintf(msg, "FRAME AQCUIRED\r\n");
HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), HAL_MAX_DELAY);
if (buf[0] == 0x0F) {
CH[0] = (buf[1] >> 0 | (buf[2] << 8)) & 0x07FF;
CH[1] = (buf[2] >> 3 | (buf[3] << 5)) & 0x07FF;
CH[2] = (buf[3] >> 6 | (buf[4] << 2) | buf[5] << 10) & 0x07FF;
CH[3] = (buf[5] >> 1 | (buf[6] << 7)) & 0x07FF;
CH[4] = (buf[6] >> 4 | (buf[7] << 4)) & 0x07FF;
CH[5] = (buf[7] >> 7 | (buf[8] << 1) | buf[9] << 9) & 0x07FF;
CH[6] = (buf[9] >> 2 | (buf[10] << 6)) & 0x07FF;
CH[7] = (buf[10] >> 5 | (buf[11] << 3)) & 0x07FF;
CH[8] = (buf[12] << 0 | (buf[13] << 8)) & 0x07FF;
CH[9] = (buf[13] >> 3 | (buf[14] << 5)) & 0x07FF;
CH[10] = (buf[14] >> 6 | (buf[15] << 2) | buf[16] << 10) & 0x07FF;
CH[11] = (buf[16] >> 1 | (buf[17] << 7)) & 0x07FF;
CH[12] = (buf[17] >> 4 | (buf[18] << 4)) & 0x07FF;
CH[13] = (buf[18] >> 7 | (buf[19] << 1) | buf[20] << 9) & 0x07FF;
CH[14] = (buf[20] >> 2 | (buf[21] << 6)) & 0x07FF;
CH[15] = (buf[21] >> 5 | (buf[22] << 3)) & 0x07FF;
if (buf[23] & (1 << 0)) {
CH[16] = 1;
} else {
CH[16] = 0;
}
if (buf[23] & (1 << 1)) {
CH[17] = 1;
} else {
CH[17] = 0;
}
// Failsafe
failsafe_status = SBUS_SIGNAL_OK;
if (buf[23] & (1 << 2)) {
failsafe_status = SBUS_SIGNAL_LOST;
}
if (buf[23] & (1 << 3)) {
failsafe_status = SBUS_SIGNAL_FAILSAFE;
}
// SBUS_footer=buf[24];
}
}
/* USER CODE END 0 */This snippet is not mine, and I've got the feeling that the translation from the values into the buffer is missing. Could that be? If so, how would that look? To keep things simple I would like to avoid DMA in the beginning.
The while-loop is basically just the channel values 1-6 being printed to the serial terminal repeatedly.
CONCLUSION: Since the serial communication itself works, but neither gets any values nor notifies for a new frame, I think the issue lies within the SBUS -> UART part of it. Means, the Callback doesnt get executed for whatever reason. Additionally, here's my .ioc:
Iv'e tried it with 9 or 8 bits word length, but that doesnt change anything. Since FrSky is using the Inverted-SBUS, which is inverted itself (0->H, 1->L), I figured the data polarity is correct aswell as the jumper wires and config settings on the RX.
Regarding the transfer to the buffer AND/OR the Callback, what are your thoughts?
I'm not quite sure I understood what you meant and also unfortunately dont have a USB-serial adapter (yet), but tried to get as close to it as possible.
I started with your data acquisition snippet. From there, I went and pasted every one of the 25 bytes from the current frame one after another into the serial terminal. To my surprise, the "0x0F" or decimal 15 was nowhere to be seen, and most definetly not around buf[0].
Below image shows the serial terminal, it notifies for a new frame with its buf[0] and then just throws out all 25 values (beginning, again with buf[0]), raw and untouched yet from any conversion. For the sake of reading, it waits a second until it pastes the next fresh frame. Leaving that last step, meaning the delay, out doesnt change a thing as it seems.
Addition: Notice how some frames have their buf[0] be a specific value after the frame notification, and then are pasted with a different buf[0] as the whole frame is pasted. Looks weird to me - does that mean the frame gets overwritten in the meantime because pasting it via serial takes too long between each frame or is that a timing issue?
For example this, buffer0 being 48, in the whole pasted frame 92.
Seems shifted to the right I guess?
EDIT2: Shorter signal wire, now down to 3cm, did not change a thing. Don't want to manufacture a whole PCB before this works honestly
EDIT3: During further research I read somewhere that the duration between each SBUS frame is around 9ms. Looked toe me like it could be relevant, even though I don't know what to make of this.
EDIT4 (to keep this thread orderly):
I am now performing conversion after each frame is received and output both raw hex values and their actual converted values (the relevant data per channel). Signal trace is as short as can be. Still no real structure behind all that...
Channels 1-16 all give results in their expected range, while being seemingly random (the transmitter remains totally still as is not being manipulated).
From the beginning.
The UART is configured to 100k baud rate, polarity is assumed to be correct, parity and word length is assumed to be correct, and the acquisition via an interrupt works too. Because, if I unplug the receiver, the input to the MCU remains constant contrary to "active" signal input with a connected receiver. I checked wether the MCU's clock signal (internal OSC) is maybe too unprecise, switched to the external 8Mhz but still got the same result.
I need an 0x0F on the first buffer value to know what follows is most likely SBUS raw data, which will later be converted. I don't get this flag often - but rarely. If I get it, no channel is similar to that of the last useful frame, despite no big movements in the joysticks. If I don't get this flag, the data is completely random aswell.
Instead I receive random and ever changing data on my UART.
As a semi-beginner, this is beyond my understanding honestly.
Today I got to test the logic analyzer. Unfortunately, that raised more questions than it answered.
Here are a few snaps from a SBUS signal that I acquired directly from the receiver, without the STM32 (solely as power source). Config-window for SBUS decoding:
These are the SBUS decoding settings, I tried every combination imaginable, first and foremost 100000kbps, 8, even parity, 2 stop bits. Switched Inverted/not inverted. 8/9 bits. Even/uneven. But all that made no difference - what follows are frames taken with several different settings where it's mostly inversion that was changed in the decoding options. Values stay untouched, so the upper "line" is always the raw, unedited signal.
As you can see in this and some following screenshots, there are some repeating patterns again, yet the same phenomenon, the "wandering", occurs too.
Am I the only one finding those frames a little short for 25bytes?
I can't even decipher more than two bytes out of most of those frames. Or is that because every byte is transmitted seperately (which, the more thought I give it, sounds somewhat plausible)?
I am 100% sure that the data line is hooked up to the SBUS-Out pin on the Receiver.
Now, there is the option to declare the "SBUS paket length" which I then tried setting to 25, 24 but that did not give me any good results either. I can try it with 16 or other values tomorrow, but as of right now it looks like a dead end.
There's a second, smaller SBUS receiver inbound for a small drone, I could use that to test wether my Rx is maybe bad or not.
In the meantime, I have no idea what to make of this - any ideas?
______
