Send data through UART port

[tomari]

Hello, using the latest firmware with 9x board and mavlink:

i would like to send evry 500ms the hex data 0xFE 0x09 0x01 0x01 0x00 through the UART port (pins 2 and 3)

i would also like to tie this to LCD backlight on/off setting so:

when the backlight setting is OFF the data is sent every 500 ms
when the backlight setting is ON the data is not sent anymore

can anyone point me to the right direction ?

every single question and problem i ever had was solved by reading this forum
now is time for custom things
but i am not 100% confident to touch everything in the code yet, a little help would be realy nice !!

thanks in advance

[tomari]

nobody? i just need a little guidance about how OpenTx manipulates these ports and i think i can do it
i couldn't find anything in the forums....

[Kilrah]

The way the serial port is handled is likely different in the mavlink build than the usual FrSky one, and nobody touched the mavlink code in years... so unfortunately I doubt anybody here knows much more than you about this on top of their head.

[tomari]

uh oh i was starting to feel bad!!
like i said something dump or....i dont know

just tell me this and i will feel a little better

if compiler doesnt complain about anything
can i still brick my 9x??

i want to test some things..but..if i screw up a function inside, lets say, mavlink.h and compiler doesnt bother
will 9x get useless? or i just flash unscrewed .hex and fly again??
i do a lot of nail biting each time i flash with noobish code inside

[tomari]

also, i dont want to send these data"through" the mavlink interface (build the message give ids crc check etc)
i just want the uart port to TX these raw data
i think that no matter what mavlink does to data before it sends, it still uses the standard functions to send/read the built message
that is my understanding of the code inside mavlink.cpp and mavlink.h
so the answere is somewhere here:
SERIAL_start_uart_send();
SERIAL_end_uart_send();
SERIAL_send_uart_bytes(uint8_t * buf, uint16_t len);
serial_startTX();

the port is already initialized the time i want to send the data

idk it might be realy easy or im realy stupid

[MikeB]

There should be no problem if you flash a version of code you build. If it doesn't work correctly, you should be able to just flash a working version and recover.
The usual care should be taken to back up your EEPROM first, and make sure you do have a known working version to flash back.

Mike.

[tomari]

thanks! that gives me confidence to noob it up a little more

i will come back with the solution i am sure!!

[Kilrah]

also, i dont want to send these data"through" the mavlink interface (build the message give ids crc check etc)
i just want the uart port to TX these raw data

Then the fist thing you need to check is whether the UART TX is already being used by the MAVLINK lib to send status/requests to the aircraft.

What you want to do is only possible if it isn't the case and the TX line is currently unused.

[tomari]

Hello, thanks for the reply, yes the TX line is free and not used by mavlink, there are some weird functions that use TX but they are all disabled! (commented out)

The part that confuses me in the serial_driver files is the "interrupt driven uart" concept that i've never used or seen. i do some reading now but im not sure i completely understand.

these are the functions about Serial TX:

Code: Select all

void SERIAL_start_uart_send() {
	ptrTxISR = serialTxBuffer;
	serialTxBufferCount = 0;
}

void SERIAL_end_uart_send() {
	ptrTxISR = serialTxBuffer;
	//UCSR0B |= (1 << UDRIE0); // enable  UDRE0 interrupt
	serialTxState = TX_STATE_READY;
}

void SERIAL_send_uart_bytes(const uint8_t * buf, uint16_t len) {
	while (len--) {
		*ptrTxISR++ = *buf++;
		serialTxBufferCount++;
	}

}

and then there is

void SERIAL_startTX(void) {
	if (serialTxState == TX_STATE_READY) {
		serialTxState = TX_STATE_BUSY;
		UCSR0B |= (1 << UDRIE0); // enable  UDRE0 interrupt
	}
}

the port is already initialized by mavlink

so, doing

Code: Select all

uint16_t bar = 3;
uint8_t foo[] = "\x01\x02\x03"; // or maybe:  uint8_t foo[3] = {0x01,0x02,0x03}; ?? im not sure!!!
SERIAL_send_uart_bytes(foo,bar); 

will send it ?
i feel that something is missing/wrong !!

[MikeB]

Either of your methods for initialisiing "foo" are OK.
It looks to me like you need to do:

SERIAL_start_uart_send();
SERIAL_send_uart_bytes(foo,bar);
SERIAL_end_uart_send();
SERIAL_startTX();

Then you data will be sent by the interrupt routine(s).

Mike.

[tomari]

thanks i tried it but i have an error

Code: Select all

void noobytestTX(void) { 
SERIAL_start_uart_send();
uint16_t len = 3;
uint8_t buf[] = "\x01\x02\x03";
SERIAL_send_uart_bytes(buf,len);
SERIAL_end_uart_send();
SERIAL_startTX();
}

error:
/mnt/hgfs/vmshare/opentx/radio/src/gui/9X/view_mavlink.cpp:302: undefined reference to SERIAL_send_uart_bytes(unsigned char*, unsigned int)

i am a little confused now

[Kilrah]

Did you actually #include the serial_driver.h file wherever you're trying to use those functions?

[tomari]

yup, the file is included

and compiler does not complain if

SERIAL_send_uart_bytes(buf,len);

is commented out

i tried adding :

extern void SERIAL_send_uart_bytes(const uint8_t * buf, uint16_t len);

in view_mavlink.h (its included in view_mavlink.cpp) but failed with the same error

i even tried puting this inside serial_driver.cpp file, just under the SERIAL_send_uart_bytes function just to see if it compiles, and it fails with the same error!!

i dont know what else to try

[tomari]

hello again, i want to explain the real reason i want to do this, in case somebody else is interested and we get a little more help.

HW Setup:
3dr Radio is installed inside the 9X in order to have telemetry on the TX screen (reposition pins mod etc)
more info: LCD backlight ON OFF is used to control a bluetooth module power and if i want to connect pc and GCS i just turn it ON or OFF
(backlight is always ON, directly powered)

Problem:
Everything works great except of PC RSSI (telemetry RSSI)
3dr radios inject telemetry rssi info only if it sees an INCOMING heartbeat:
~the algorithm inside 3dr radios looks at incoming msg and if it sees:
--byte 0 = FE
--byte 1 = 09
--byte 5 = 00
it injects this info (and some other that i want to use too)

openTX reads telemetry passively transmitting nothing so this info is not injected.

tests:
~while openTX is connected and reads Telemetry through 3dr, getting no PC RSSI info, i connected my pc to TX pins and injected this:
FE 09 00 00 00 00
~ 3drs immediatly responded and injected the RADIO_STATUS info

Solutions:
1) have your TX connected to a laptop/tablet/pc and a custom software sending FE 09 00 00 00 00 every X ms (tested, works)
~ not good!! if i could have a pc connected with my TX why should i put the 3dr ground module inside my 9x and not just connect it to my pc??

2) have your TX connected to a laptop/tablet/pc and MissionPlanner or othe GCS connected (tested, works)
~ not good!! if i could have a pc connected with my TX why should i put the 3dr ground module inside my 9x and not just connect it to my pc??

3) short RX TX pins in ground module (that is inside my 9x) this way pixhawk's heartbeat is loopbacked from ground module and the remote module gets the "fake" heartbeat that triggers READIO_STATUS injection. (tested, works)
~ this works but isn't it nasty? aren't we overloading pixhawk with rejected (by msg count and msg id filtering) messages? i dont have problem doing this but is it ok? (i can put a solid state relay tied to LSD backlight ON OFF so when bluetooth is used to relay telemetry to PC the pins are not shorted)

4) put an arduino inside the 9x, controll the sending or not of the "fake" heartbeat the same way as 3
~ come on! isn't this an overkill?

5) make openTX transmit this fake "heatbeat" when LCD backlight is OFF.
~this is what i am trying to do

6) modify 3dr's firmware and make it always inject the radio_status info
~i dont know what other problems this is going to rise and what other compatibility will break. I dont want to play with it wanyway!!

so since i have been trying for many days and fail, i am ready to give up!! do you think that doing the 3 will pose a problem anyway? i can even use a pc jumper

[Kilrah]

5) is obviously the best solution, and 3) could have unexpected results indeed.

Now, read a bit:

extern void SERIAL_send_uart_bytes(const uint8_t * buf, uint16_t len);

So...

const uint8_t buf[] = "\x01\x02\x03";

[tomari]

dear killah, i am a completely stupid noob.

u cant imagine what things i tried and did not see this error...

i digged so deep for hours and hours and tried so many stuff (i just deleted 100s of commented lines!!)

Code: Select all

void noobtx(void) { //i am a supernoob!!!!
SERIAL_start_uart_send();
uint16_t len = 6;
const uint8_t buf[] = {0xFE,0x09,0x00,0x00,0x00,0x00};
SERIAL_send_uart_bytes(buf,len);
SERIAL_end_uart_send();
SERIAL_startTX();
}

this worked like a charm!!!!!!
it works so good, you can hear the bits inside the TX cable singing!!

now i have to find how timers work in openTX
i triggered the send by pressing right just for testing!

[tomari]

worked like this with 90ms interval:
@ opentx/radio/src/gui/9x/view_mavlink.cpp

Code: Select all

tmr10ms_t start = get_tmr10ms();
void PcRssiTriggerTx(void) { //i am a supernoob!!!!
if ((get_tmr10ms() - start) >= 9){
	SERIAL_start_uart_send();
	uint16_t len = 6;
	const uint8_t buf[] = {0xFE,0x09,0x00,0x00,0x00,0x00};
	SERIAL_send_uart_bytes(buf,len);
	SERIAL_end_uart_send();
	SERIAL_startTX();
	start = get_tmr10ms();
	}
}

then inside every
void menuTelemetryMavlink**** menu
you just put a
PcRssiTriggerTx();

next is to figure how to read if backlight setting is on or off

i will upload ready hex when all works
+a bonus menu with lots of info !

[MikeB]

Nothing wrong really with your code, but you might like to change the line:
start = get_tmr10ms();
to
start += 9 ;
It is possible your test for >=9 is true because the difference is 10. In this case, you 'slip' 10mS. Using += 9 means you only wait 80mS to the next send, and don't 'slip' permanently.

Mike.

[tomari]

Hello Mike, thanks for the tip!

i changed the line and i noticed a consistent 70 Characters per second transmited through the port so it works nice!
i also found the way to tie it to Backlight ON/OFF and this works good
then i noticed a bug
if i exit the mavlink menu (and transmition stops) for lets say 10 seconds
then when i get in again the if ((get_tmr10ms() - start) >= 9) evaluates each time and i get a continues burst of transmited data for aprox 10 secconds (as high as 270 Characters per second) i made a little change in the code again and now this bug went away

it goes like this now:
@ opentx/radio/src/gui/9x/view_mavlink.cpp

Code: Select all

tmr10ms_t start = 0;
 void EntryTmrReset(void){
	start = get_tmr10ms();
}

then i added one line here

Code: Select all

void menuTelemetryMavlink(uint8_t event) {
	
	switch (event) // new event received, branch accordingly
	{
	case EVT_ENTRY:
		MAVLINK_menu = MENU_INFO;
		EntryTmrReset();  /// <------------------- Reset timer each time we enter the view_mavlink menu
		break;
...
...

and this is how i handled the backlight On off

Code: Select all

void PcRssiTriggerTx(void) { //i am a supernoob!!!!
	if (g_eeGeneral.backlightMode == e_backlight_mode_off){
		if ((get_tmr10ms() - start) >= 9){
		SERIAL_start_uart_send();
		uint16_t len = 6;
		const uint8_t buf[] = {0xFE,0x09,0x00,0x00,0x00,0x00};
		SERIAL_send_uart_bytes(buf,len);
		SERIAL_end_uart_send();
		SERIAL_startTX();
		start += 9 ;
		}
	}
}

thanks for the help and support!
i was ready to give up..

[tomari]

Hello, sorry for being lost these days but i have work to do.
i attach the ready hex file and some self explanatory pictures

[LTMNO]

What were you running on the 9x?
Opentx with Mavlink Option?

This is the only thread i have been able to find with someone doing anything with 9x. not the 9xr or 9xrpro.
All i have is 9x's and really want to get Mavlink going on it.

Thanks for posting.

So your Hex files is for the Arduino?

[tomari]

hello my firend, this is 9x with mavlink.

i think you are somehow confused ?
you dont need an arduino to do this

this is for using 3dr telemetry inside your 9x

the hex file is for the 9x to flash

[tomari]

some self explanatory pictures

i had a dead 3dr ground station (almost dead, the usb interface was dead in reality)

1) reposition the switch pins of 9x
2) use the free pins as RX and TX
3) i powered the 3dr with a ubec and a 5v to 3.3v regulator

[tomari]

more pics

[LTMNO]

Thank you!
Was there just the one screen?
Also, did you get good voice commands setup for this interface?
Would love to see them.

Cheers!