Telemetry Protocols

Post by **jhsa** » Thu Sep 25, 2014 8:38 am

Yes of course. Please open another thread explaining the problem. We should leave this thread only for discussing the protocols development, otherwise it will become a mess

I have a feeling you will find the problem.

João

Post by **MikeB** » Fri Sep 26, 2014 6:21 pm

Just committed the source files. The 9XR-PRO now the start of support of MAVLINK. There is an option in the TELEMETRY menu to select MAVLINK (instead of FrHub).
There is a new file "mavlink.h" that includes a define for tha baudrate.
There is a new file "mavlink.cpp" that just has a single procedure "void mavlinkReceive( uint8_t data )". This is called with every received telemetry data byte when MAVLINK telemetry is selected.

Mike.

cxlabs · Post by **cxlabs** » Sun Sep 28, 2014 7:31 pm

Hi Mike,
just checked out latest ersky (r212) and try make (under linux)
_________________________________________________________________________________
root@cxlabs:/usr/local/src/ersky9x/ersky9x-r212/src# make

Generate Version-stamp:
arm-none-eabi-gcc -c -mcpu=cortex-m3 -Os -gdwarf-2 -mthumb -fomit-frame-pointer -Wall -Wstrict-prototypes -fverbose-asm -Dat91sam3s4 -DRUN_FROM_FLASH=1 -DPCBSKY -DSTAMP -DFRSKY -DCPUARM -MD -MP -MF skyobj/core_cm3.o.d -I . -I./inc core_cm3.c -o skyobj/core_cm3.o
core_cm3.c:802:1: fatal error: opening dependency file skyobj/core_cm3.o.d: No such file or directory
compilation terminated.
make: *** [skyobj/core_cm3.o] Error 1
_________________________________________________________________________________
--> ok , only skyobj dir is missing

root@cxlabs:/usr/local/src/ersky9x/ersky9x-r212/src# mkdir skyobj

... debug.cpp:62:19: fatal error: Audio.h: No such file or directory

--> ok first char upper case problem

... file.cpp:38:23: fatal error: Stringidx.h: No such file or directory

--> ok first char upper case problem
... templates.cpp:45:23: fatal error: Stringidx.h: No such file or directory
.. pers.cpp:27:23: fatal error: Stringidx.h: No such file or directory
... menus.cpp:36:23: fatal error: Stringidx.h: No such file or directory
... ersky9x.cpp:61:23: fatal error: Stringidx.h: No such file or directory
--> same as up

After changing the include, make (make REVB=1 DEBUG=1 STAMP=1 PHASES=1) works ok...
Now load and test it..

cxlabs · Post by **cxlabs** » Sun Sep 28, 2014 7:58 pm

hi

my skynorth rev B Radio stop working even by usb connection on...
Time to recall old jumper settings to revive bootloader...
Sorry Mike, i can't go on testing (for now)

=================================================================================
Started SAM-BA
C:\Program Files\ATMEL Corporation\sam-ba_2.11\sam-ba.exe \USBserial\COM9 at91sam3s4-9x C:/DOCUME~1/name/LOCALS~1/Temp/temp.tcl
=================================================================================
-I- Waiting ...
-I- TCL platform : Windows NT
-I- SAM-BA 2.11 on : windows
-I- Retrieved arguments from command line :
-I- argv 0 : \USBserial\COM9
-I- argv 1 : at91sam3s4-9x
-I- argv 2 : C:/DOCUME~1/name/LOCALS~1/Temp/temp.tcl
-I- Connection : \USBserial\COM9 (target(comType) = 0)
-I- Board : at91sam3s4-9x
-I- Traces Level : 4
-I- target(handle) : 20803208
Read device Chip ID at 0x400e0640 --- get 0x00000000
Read device Chip ID at 0x400e0740 --- get 0x28a00960
-I- Found processor : at91sam3s4 (Chip ID : 0x28a00960)
sourcing device file C:/Program Files/ATMEL Corporation/sam-ba_2.11/sam-ba.exe/../tcl_lib/devices/at91sam3s4.tcl
sourcing board description file C:/Program Files/ATMEL Corporation/sam-ba_2.11/sam-ba.exe/../tcl_lib/at91sam3s4-9x/at91sam3s4-9x.tcl
-I- Loading applet applet-lowlevelinit-atsam3s4.bin at address 0x20001000
-I- Memory Size : 0x0 bytes
-I- Buffer address : 0x4
-I- Buffer size: 0x0 bytes
-I- Applet initialization done
-I- Low level initialized
-I- Loading applet applet-flash-atsam3s4.bin at address 0x20001000
-I- Memory Size : 0x40000 bytes
-I- Buffer address : 0x20001C40
-I- Buffer size: 0xA200 bytes
-I- Applet initialization done
-I- FLASH initialized
-I- Command line mode : Execute script file : C:/DOCUME~1/name/LOCALS~1/Temp/temp.tcl
-I- Send File Z:/ersky9x-r212/src/ersky9x_rom.bin at address 0x400000
first_sector 0 last_sector 10
-I- Complete 0%
-I- Writing: 0xA200 bytes at 0x0 (buffer addr : 0x20001C40)
-I- 0xA200 bytes written by applet
-I- Complete 23%
-I- Writing: 0xA200 bytes at 0xA200 (buffer addr : 0x20001C40)
-I- 0xA200 bytes written by applet
-I- Complete 46%
-I- Writing: 0xA200 bytes at 0x14400 (buffer addr : 0x20001C40)
-I- 0xA200 bytes written by applet
-I- Complete 70%
-I- Writing: 0xA200 bytes at 0x1E600 (buffer addr : 0x20001C40)
-I- 0xA200 bytes written by applet
-I- Complete 93%
-I- Writing: 0x2C58 bytes at 0x28800 (buffer addr : 0x20001C40)
-I- 0x2C58 bytes written by applet
-I- GPNVM1 set

=================================================================================
SAM-BA done - SUCCESSFUL
=================================================================================

Post by **MikeB** » Sun Sep 28, 2014 9:38 pm

Looks like a successful flash using SAM-BA. Does the radio not start up now?

Mike.

cxlabs · Post by **cxlabs** » Mon Sep 29, 2014 9:30 am

Hi Mike,
YES, my turnigy skynorth revb equipped doesn't boot... with or without usb
is completely died.
I am not worried since I remember there was a jumper to set and bypass normal boot..
(i have to look for right procedure)
Then i'll try with official r212 hex to eliminate linux-gcc compilation doubts..

I will be great if you change source file includes (eg Stringidx ) to allow
native linux compilation:
Windows compilation should not be affected i think...

Anyway thank you and nice day

Post by **MikeB** » Mon Sep 29, 2014 2:26 pm

There is an "erase" jumper place, just left of the "EXTERNAL" connector above the USB connector. You short the erase pins together, then switch on for a couple of seconds. Then switch off and remove the short.
This erases the flash memory, and also clears the 'fuse' so the processor boots into the rom bootloader.
You then need to use SAM-BA to flash the program and change the "fuse" (GPNVM1) to allow booting into flash.

BEFORE doing that, you might check all connectors are fully plugged in, and also check the voltages on the regulator.

Are you using the bootloader (hold horizontal trims inwards) to flash the board? If you do, then that should continue to work even if you flash bad main firmware as the bootloader is not updated that way.

I've edited the source files so the uppercase problem will go away.

Mike.

cxlabs · Post by **cxlabs** » Mon Sep 29, 2014 10:51 pm

Success!
I unbriked and loaded r202 successfully, but initially can't make r212 work.
I tried loading via sam-ba and via SD card w/o success (probably missed the magic "make clean")

Here is my make command (copied from compile-win.cmd)
make clean
make REVB=1 DEBUG=1 STAMP=1

I'll start including MAVLINK standard defines and cpp

Only two little notes:
1. on menu 10/14 we can choose ArduP but DSMx appears when you leave

2. 'obj' directory is missed in src/bootloader: when i create it, 'make' works better

Thank you a lot!

Post by **MikeB** » Mon Sep 29, 2014 11:05 pm

I'll check what I have enabled. I do have a difference between the SKY board in a 9X and the 9XR-PRO when selecting telemetry protocols.

Do you have eepskye installed? You should be able to flash directly using that without needing SAM-BA. I find it the quickest way!

Mike.

cxlabs · Post by **cxlabs** » Tue Sep 30, 2014 10:33 am

Yes, i've used eepskye the very first time, but leaved it when suspecting
it overwrites bootloader..
I will use eepskye for next loadings

Next steps in my mind is:
1. include MAVLINK defines and basic functions
2. create a switch in your callback fn - void mavlinkReceive( uint8_t data )
3. load mavlink data in standard global vars for display

The first and second step could be easy to realize by me, not the third one..

I attach the basic MAVLINK defines to explain better my idea.

Thank you, nice day

Post by **MikeB** » Tue Sep 30, 2014 10:38 am

eepskye does NOT overwrite the bootloader.
I'll look at the defines later, off flying shortly!

Mike.

cxlabs · Post by **cxlabs** » Tue Oct 07, 2014 2:00 pm

Hi Mike,
I dirty include mavlink functions to ersky sources.

In detail i adapted two directories taken from openTX,
add a call ( MAVLINK_rxhandler(data); ) in mavlink.cpp
and compile it.

One question: is there a simple way to show data on LCD display?
(Just for test)

Thank you! nice day

Radian · Post by **Radian** » Fri Oct 17, 2014 9:23 pm

cxlabs - I've been dumping MAVlink data all day in an attempt to extract the sort of info I would like to display. Looking for bit-field descriptions I ended up examining the message description .xml files but not everything ties up with the actual data I get back from an APM2.6 stream. Do you think it's even sensible to treat MAVlink as a "standard"? For example, the "MAV_MODE" byte (heartbeat packet) would seem to have useful info about arming states but the actual byte is always zero regardless of what state my AP is in. On the other hand "custom_mode" described as "A bitfield for use for autopilot-specific flags." looks very busy. But if it's different for each AP then this doesn't seem to offer a general way of presenting telemetry (short of extra look-ups - for which I can't seem to find the relevant docs). I'd be interested to hear your take on this.

Radian · Post by **Radian** » Mon Oct 20, 2014 8:29 am

I can save the time of anyone else replying by saying that I worked out what was wrong. The values appear to be packed in a different order to the descriptions given in the most widely referenced doc e.g: https://pixhawk.ethz.ch/mavlink/#HEARTBEAT I had to find an example of source code that actually stuffs the message packet payload to discover this. From that I can see that values are packed in descending order of word length - presumable for word aligned access?

I wish I'd been in on this game from the beginning as there's a fair bit of history to it. It looked pretty well written-up to me but it's becoming clear that there's an awful lot that's hidden under the hood. I still don't know if it's practical to provide a general MAVlink telemetry parser that doesn't have to be re-compiled each time to suit different implementations or not. Put another way, if I wanted to develop a visual signalling system that conveyed useful vehicle status information (read blinky LEDs) would this be practical? I assume it must be because OSD video adapters must be performing a similar task. But then there's this thing I'm still trying to get my head around about .xml descriptors of messages that auto generate decoding structures...

cxlabs · Post by **cxlabs** » Tue Oct 21, 2014 10:07 am

Hi Radian,
if it can help, i modified opentx 2.12 for sky9x boards
(i want to keep working on ersky9x, but opentx job was easier thanks to pienk user)

My git branch is https://github.com/adriano65/opentx-mavlink
I tested it on my sky9x+openlrsng3.1.7+arduplane2.75 and works fairly well:

in radio/gui/view_mavlink.cpp there are functions to interface mavlink

hope little help

cxlabs · Post by **cxlabs** » Tue Dec 30, 2014 2:21 am

Hi Mike,
i am trying to TX some data on my SKY9X and 9XRPRO radio.
Nothing happens on serial line (USART0 on Sky9x, UART0 on 9XRPRO)
My oscilloscope reads 0 volt on 9xrpro and -8 volt on sky9x.

The sky9x voltage readings seems ok and the problem could be in my FW modifications,
but the zero volt on 9xrpro suggest me some I/O initialization missed.

Now, i'd like to use 9xrpro for tests instead of sky9x (that is my main radio)

Is there some IO pin to enable for rs232 drivers on 9xrpro ?

Thank you in advance, happy new year

Post by **MikeB** » Tue Dec 30, 2014 9:49 am

The voltages are OK, the SKY board has full RS232 buffers (+/- volt drive), while the 9XR-PRO has transistors so doesn't drive negative.

By default, the UART0 is configured to 9600 baud, and a debug task is connected to to it. This happens unless you allocate "COM2" to telemetry.
You can test this by connecting a normal serial port on your PC to it, running a terminal program (9600 baud) and typing the character V (uppercase V). You should get a version number output.

Mike.

cxlabs · Post by **cxlabs** » Tue Dec 30, 2014 10:02 pm

Thank you for quick answer: voltages values are crystal clear now

I clone the TX task structure from bluetooth.cpp (opentx)
but writing with void debugPutc(const char c) (when i use 9xrpro serial to RFmodule)
seems doing nothing...
Also tried with txPdcBt(struct t_serial_tx *data) (when i use 9xrpro externally wired bluetooth serial)

I'll study code deeper ...

Thank you
Adriano.

Post by **MikeB** » Tue Dec 30, 2014 11:37 pm

This may help. I've added a facility for the direct connection between bluetooth and COM2 so data passes through in both directions. This includes the driver code for sending data on COM2 (in drivers.cpp). This is tested and working.

You can see where it is used in bt_task() in ersky9x.cpp.

bt2com2.zip: (50.7 KiB) Downloaded 206 times

Mike.

cxlabs · Post by **cxlabs** » Fri Jan 02, 2015 9:28 pm

Thank you, Mike.
I unzipped files in r212 src dir, but
drivers.cpp:910:34: error: 'COM2_FUNC_SBUSTRAIN' was not declared in this scope
drivers.cpp:910:85: error: 'COM2_FUNC_SBUS57600' was not declared in this scope
drivers.cpp:914:37: error: 'COM2_FUNC_BTDIRECT' was not declared in this scope

then i check menus.cpp to discover #define values:
maybe
CHECK_INCDEC_H_MODELVAR_0(event, g_model.com2Function, 1 ) ?
i mean, can i #define COM2_FUNC_SBUSTRAIN 1 ? and so on ?
...or can you send me the correct ones

Anyway i'll look at bt_task() in ersky9x.cpp.

Thank you a lot

Post by **MikeB** » Fri Jan 02, 2015 9:44 pm

I have the defines in ersky9x.h:

Code: Select all

// COM2 Functions
#define COM2_FUNC_TELEMETRY		0
#define COM2_FUNC_SBUSTRAIN		1
#define COM2_FUNC_SBUS57600		2
#ifdef PCBSKY
#define COM2_FUNC_BTDIRECT		3
#endif
#ifdef PCBX9D
#define COM2_FUNC_CPPMTRAIN		3
#endif

Also the code in menus.cpp for this is now:

Code: Select all

		lcd_puts_Pleft( y, XPSTR("COM2 Func.") );
		uint8_t b = g_model.com2Function ;
    attr = 0 ;
		if ( (sub == subN) )
		{
			attr = INVERS ;
#ifdef PCBSKY
	  	CHECK_INCDEC_H_MODELVAR_0(event, g_model.com2Function, 3 ) ;
#endif
#ifdef PCBX9D
	  	CHECK_INCDEC_H_MODELVAR_0(event, g_model.com2Function, 3 ) ;
#endif
		}
#ifdef PCBSKY
		lcd_putsAttIdx(12*FW, y, XPSTR("\011TelemetrySbusTrainSbus57600BTdirect "), g_model.com2Function, attr ) ;
#endif
#ifdef PCBX9D
		lcd_putsAttIdx(12*FW, y, XPSTR("\011TelemetrySbusTrainSbus57600CppmTrain"), g_model.com2Function, attr ) ;
#endif
		if ( g_model.com2Function != b )
		{
#ifdef PCBX9D
			if ( b == 3 )
			{
				stop_serial_trainer_capture() ;
			}
#endif
			if ( g_model.com2Function == COM2_FUNC_SBUSTRAIN )
			{
				UART_Sbus_configure( Master_frequency ) ;
			}
			else if ( g_model.com2Function == COM2_FUNC_SBUS57600 )
			{
				UART_Sbus57600_configure( Master_frequency ) ;
			}
#ifdef PCBSKY
			else if( g_model.com2Function == COM2_FUNC_BTDIRECT )
			{
				UART_Configure( g_model.com2Baudrate, Master_frequency ) ;
			}
#endif
#ifdef PCBX9D
			else if( g_model.com2Function == COM2_FUNC_CPPMTRAIN )
			{
				init_serial_trainer_capture() ;
			}
#endif
			else
			{
				if ( g_model.frskyComPort == 1 )
				{
					telemetry_init( TEL_FRSKY_HUB ) ;
				}
				else
				{
					// Set for debug use
#ifdef PCBSKY
					UART_Configure( 9600, Master_frequency ) ;
#endif
#ifdef PCBX9D
					x9dConsoleInit() ;
#endif
				}
			}
		}
	  y += FH ;
		subN += 1 ;

Mike.

cxlabs · Post by **cxlabs** » Fri Jan 02, 2015 9:56 pm

I am sorry, but
ersky9x.cpp:77:18: fatal error: sbus.h: No such file or directory

and

menus.cpp:2409:37: error: 'SKYModelData' has no member named 'com2Baudrate'

what about zipping and uploading whole src directory ?

Thank you again

Post by **MikeB** » Fri Jan 02, 2015 11:25 pm

Too many other files in my source directory you won't want for that.
What I have done, however, is to commit the sources as I have them, without committing any new .bin files.

Mike.

cxlabs · Post by **cxlabs** » Fri Jan 02, 2015 11:39 pm

JUST DONE!

make REVB=1 DEBUG=1 STAMP=1
....
arm-none-eabi-objdump -h -S ersky9x_rom.elf > ersky9x_rom.lss
text data bss dec hex filename
186756 448 26504 213708 342cc ersky9x_rom.elf
root@cxlabs:/usr/local/src/ersky9x/ersky9x-r213/src#

I'll let you know my oscope response

Thank you!

handsomejackuk · Post by **handsomejackuk** » Sun Jan 04, 2015 2:23 pm

can anyone confirm if a frsky djt module can be connected directly to a bluetooth module hb01 or similar product to send telemetry data to an android device running multiwii ez-gui or frsky app....

i have a turnigy 9xr but dont really want to do the telemetry mod unless i get a spare main board...

i would be happy with an android phone on my transmitter and little mods as possible...

sorry if this has been asked before... but if someone could point me in the correct direction

Post by **MikeB** » Sun Jan 04, 2015 5:58 pm

I don't know that particular BT module. The DJT outputs full RS232 (+/-6Volts), so you need to check if your BT module accepts this, or if it is expecting a logic level signal.

Mike.

handsomejackuk · Post by **handsomejackuk** » Sun Jan 04, 2015 6:10 pm

ok thanks Mike i just thought it may be a popular mod with the ezgui app giving so much infomration, and android phones so popular. i have bluetooth working on my quad great with the ez-gui app but the range is limited to only 10m i have a search about to see if anyone else knows or have done a similar thing

KAL · Post by **KAL** » Sun Jan 04, 2015 7:01 pm

If you want to send the incoming telemetry data of djt/dht to bluetooth module you have to
do a part of the telemetry mod:

mod the djt/dht to output ttl level (not recommended) or
convert the rs232 level signals of djt/dht to ttl via a converter in a way like this

The connections that normally go to MISO and MOSI on the mainboard then have to be connected
to your bluetooth module.

Edit: the data you(your quad) send(s) into your frsky receiver must be frsky compatible.

Klaus

Post by **jhsa** » Sun Jan 04, 2015 7:09 pm

Also some bluetooth modules might need a voltage divider on the RX line as they accept only 3.3V levels..

João

handsomejackuk · Post by **handsomejackuk** » Mon Jan 05, 2015 11:08 am

ok thanks i got a bit further now..... will continue to research this avenue

openrcforums

Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

MAVLINK Telemetry Protocol

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols

Re: Telemetry Protocols