OpenxGPS?

[Maguro]

What is the chance of being able to port existing GPS to Open architecture using Sbus? I have a a perfectly good EagleTree V3 GPS that I'd love to use with my Taranis. I suppose the Sbus-UART module would allow the data to be transmitted, but it's no use without supporting software. Is anyone interested in this project?

[mstrens]

Did you had a look at this link?
http://www.diydrones.com/forum/topics/a ... -converter
Perhaps it can help.

Otherwise, I expect it should be possible to use an arduino pro mini (as it is done for openxsensor) to collect the GPS data and to convert them for SPORT protocol. So the GPS data would be available in taranis telemetry panels.
I have a version of openxsensor that support SPORT protocol. You can have this program if you want but it should be adapted to collect the data from the GPS.

[Maguro]

Thanks, that would be very helpful.

[Maguro]

Thanks, For the offer. Your code would be a big help.

[mstrens]

Thanks, For the offer. Your code would be a big help.

Here my version of openxsensor.
There are quite many changes compared to the version r197 on google.
The changes in order to transmit more fields on SPORT protocol, are (mainly) in Aserial.cpp and in xos_out_frsky.cpp.
You can have a look at the config.h file too in order to understand how it can be configured.

If this is not clear enough, don't hesitate to send your questions.

[Maguro]

I settled on a combination of software. I use Adafruit's GPS software combined with Mavlink_FrSkySPort software for SPort access. I'm getting data on the Taranis, but it isn't all correct. Lat and Long degrees are correct, but minutes aren't. I should have it all working properly in a few days.

Roger

[mstrens]

I settled on a combination of software. I use Adafruit's GPS software combined with Mavlink_FrSkySPort software for SPort access. I'm getting data on the Taranis, but it isn't all correct. Lat and Long degrees are correct, but minutes aren't. I should have it all working properly in a few days.

Roger

FYI, do not forget that 2 bytes (0x7E and 0x7D) may not be sent to RX over SPORT protocol (because 0x7E is the code that all sensors are looking for polling ; 0x7E is then replaced by 0x7D followed by the byte ^ 0x20; therefore if the byte to transmit is 0x7D it is replaced by 2 bytes too ).
So if you have to transmit one of those values, you must send 2 bytes instead of one.
I am not sure that this has been done in the original code for Mavlink
Here the code that do the conversion in openxsensor

if ( ByteStuffByte )
{
SwUartTXData = ByteStuffByte ;
ByteStuffByte = 0 ;
}
else
{
if ( TxCount < 7 ) // Data (or crc)?
{
SwUartTXData = TxData[TxCount] ;
Crc += SwUartTXData ; //0-1FF
Crc += Crc >> 8 ; //0-100
Crc &= 0x00ff ;
}
else
{
SwUartTXData = 0xFF-Crc ; // prepare sending check digit
}
if ( ( SwUartTXData == 0x7E ) || ( SwUartTXData == 0x7D ) )
{
ByteStuffByte = SwUartTXData ^ 0x20 ;
SwUartTXData = 0x7D ;
}

[Maguro]

The Lat-Long problem was easy to sort out. The GPS works beautifully now. The code I used is available for anyone who wants it.

I'm thinking of adding an airspeed sensor now. The problem is a lack of an SPort definition for airspeed. Does anyone know what FrSky is going to use on the yet to be released airspeed sensor?

Roger

[towbar]

Hi would love to try that code - am hoping to get GPS data from the Naza GPS and and inject via openxsensor.

[Maguro]

Hi would love to try that code - am hoping to get GPS data from the Naza GPS and and inject via openxsensor.

I need to make a small correction to lat/long to make the code work properly on the other side of the world. I also need to check to make sure I have the 0x7E/0x7D conversion that mstrens mentioned in my code. As soon as I get it done I'll post the code here.

[cshunt]

Hi Maguro,

I also would like to try your code. My arduino code knowledge is a bit limited. I have a functioning voltage sensor using openxsensor but have not had luck modifying the mavlink code to work on the arduino 328 in lieu of the teensy's smt32. I would assume you can read the gps sensor at 9600 through the hardware serial and then output lat/long data through an inverted 57600 software serial or aserial sketch.

-Cody

[cshunt]

I worked with the openvario code and then found a program for the teensy 3.1 to translate mavlink data to s.port. A modified version translated gps data to s.port but was made for the teensy. I worked with a modified version made for the naza to get it to run on the atmega 328. The attached code can take a serial gps module convert data with a arduino (im using a pro mini) and output to x8r receiver s.port. all can be powered by the s.port.

If anyone is interested let me know how it works.

Thanks,
Cody

[nigelsheffield]

Would this work with the. http://www.ebay.co.uk/itm/New-1PC-Ublox ... 5d53596fe2

Arduino ublox GPS? Going to a nano or , I read that the GPS uses 3.3v logic and saw that a couple of resistors on gps RX to fix this .
Just read it is only 1hz???
I just want a better GPS option for the gps triangle racing script then the frsky option which is very laggy.
Sorry for my ignorance here , if there is somewhere better to discuss my needs please let me know.
Thanks

[kalle123]

Just read it is only 1hz???

Then use https://www.u-blox.com/en/evaluation-to ... enter.html for making your settings ...

br

[nigelsheffield]

Interesting thanks, so can the 1hz be upped then? I am a complete novice here, I see the baud rate can be changed from 9600, which device is needed to program?

[kalle123]

You'll need a usb uart to connect to your pc. A cp2102 will do.
http://www.ebay.co.uk/sch/i.html?_from= ... t&_sacat=0
br

[nigelsheffield]

So is it different to ftdi cable?
Regarding the logic levels from my arduino nano to sensor board , does the sensor board need 3.3v levels or 5v?
I am getting a nano and the usual 5611 sensor board and need to be really clear as to what to power it all with and what if any tx levels need shifting with resistors???
Tia.

[kalle123]

If you have an ftdi, that is ok. If you don't have a ftdi, a cp2102 is cheaper. That is all.

Talking about the u-blox gps from ebay. It says Power supply :3V-5V

I have here two crius gps modules, which are basically the same. Work fine with ftdi or cp2102.

[nigelsheffield]

I think I understand it now, 3.3v data can be fed into a 5v chip and will be understood usually , 5v data needs limiting with resisors if being fed into a 3.3v chip.
If supply is 5v like usb but board is 3.3v only then there too needs either a 3.3v reg or resistors.
Pretty simply really, but I wanted to make sure I got it really clear before I start as I only ordered one set and did not want to make silly mistake and blow it right away.
Many sensors boards seem to have 3.3v reg on board so data could be 3.3v or is this just used for the sensor and not the data? so if sending data to these it needs to be be 3.3v and not 5v I assume, so when updating these boards a resistor divider should be used on data line?
I also read that just putting a 100k in line works rather then a divider , obviously this is easier to do.

Looking at the GPS I am guessing the logic is 3.3v so connecting to a programmer might need level shifting.

[kalle123]

Your ebay GPS and mine Crius have RS 232 serial connection.

Don't mix it up with a I2C!

br

[jhsa]

I wonder how it would be if they were mixed IRS2322C??

Sorry guys, couldn't help it..
João

[kalle123]

João,you are known for that ...

Seems to me, Nigel is mixing up I2C with that interface on the gps module.

[nigelsheffield]

Yeah, confused and mixed up are a fairly common state for me lmfao!
So I am still pretty much in that state now but starting know how confused I am rather then just being ignorant and blissful lol!!!
Thanks for your patience guys, and any humour is always appreciated.

Ftdi uart etc still has my scratching my head, I need to do some reading!

[jhsa]

You find lots of healthy humor in this forum and next to nothing of some nasty stuff you find in some other forums.. And we want to keep it like this

João

[nigelsheffield]

Great, there will be no nasty stuff from me and I can promise to TRY the odd joke now and then!
So hopefully I am armed with enough info to at least not see the magic smoke when my goodies arrive!
Just might have a few more questions once I start to try to get it working.

[cshunt]

I think the limit on some of the better ublox gps is 10 hz. Some are limited to 5 hz. Im not sure what the update rate over the frsky s.port connection would be.
Direction may have a bit of lag with a gps, it would have to wait for a change in position to give you a heading, thats where the apm/ardupilot use the magnetic compass.

Haven't messed with i2c much.. looks like oxs has a quite a few options for sensors connecting with it.

[mstrens]

oxs is based on a microprocessor AVR 328P (used in Arduino pro mini).
It can easily read data over I2C. This kind of interface is already used for the baro sensor (MS5611) and the airspeed sensor (4525D0).
A great advantage of the I2C is that it is bus and so the same pins can be connected to several sensors (each sensor having is own internal adrress ID reacts only when the master of the bus refers to it).

328P has only one UART supported by hardware but this one is not used by oXs becasue the Frsky SPORT interface uses an inverted signal that this UART does not support.
Therefore oXs use a software UART (for the FRSKY and Multiplex telemetry protocols) that make handling of interrupts more time critical. So I am not sure that implementing a second software UART will work.
Probably that if a UART has to be used for the GPS, the hardware UART will be easier.
Still this UART is used in debug mode to send debug messages to the PC. Perhaps it could be shared between the GPS and the PC

[nigelsheffield]

I'm out if my depth but sound like it might be doable then?
Would it mean the debug mode could be used only without the GPS?
A cheap GPS option that probably will work better then frsky own offering would be very cool!

[mstrens]

I think the limit on some of the better ublox gps is 10 hz. Some are limited to 5 hz. Im not sure what the update rate over the frsky s.port connection would be.
Direction may have a bit of lag with a gps, it would have to wait for a change in position to give you a heading, thats where the apm/ardupilot use the magnetic compass.

Haven't messed with i2c much.. looks like oxs has a quite a few options for sensors connecting with it.

The update rate of sport depends on the number of sport devices connected on the bus. If there is one one device, it can answer to Rx polling once every 24ms (if it react only to one device ID).
If it is programmed to react to any device ID it could send even evey 12 ms but then no other device can put on the bus.

I2C is quite easy to implement on arduino because there are libraries to support it.

Note : even if hardware UART is used (e.g. to communicate with GPS), it is possible to debug using the SPI intercace and a second arduino. Here a link that explain how it works
http://www.utopiamechanicus.com/article/spi-debug

[nigelsheffield]

Seems a good way of debugging ,
24ms is much more speed then would be needed for GPS, 500ms would be plenty fast enough for most applications and I bet the ublox won't be that fast anyway.
The frsky is reported to update as slow as once every 10 seconds I think or at least lag is something like that!?!?!?