67 replies to this topic

[FredericG]

Yesterday i received my Eagletree standard OSD and I started looking at the protocol.

It seems very simple . The address is 0x30 and periodically the logger sends a big message (63 bytes) to the OSD. I believe that the message contains all sensor data and that the OSD takes the data and displays it as it is configured before.

For one of the bytes, I already know what it means: the battery voltage. When I mimic the message with my OP board, the OSD works

http://www.vimeo.com...eo.com/12438625

Now, we need to find out, byte per byte what it means... Somebody who has an OP board and an ET OSD feels like helping?
Somebody has a ET GPS? Do you know what baudrate and what NMEA messages are expected?

Later, we could also find out how the configuring works, so that we could configure the OSD from the GCS...

Frederic

[dankers]

Fantastic!

Regarding the GPS, please see this thread on RCG:

http://www.rcgroups....d.php?t=1257119

It is a MediaTek 3329 based unit so I would certainly think the OP GPS will work with it if you change the baud rate using the MTK config Tool to change the OP GPS to match the ET one.

Hmmm... Do you have an OP GPS yet?

[Sambas]

Cool, I just ordered ET OSD (Hoppyking sale 32.50$) I can help you when it arrives. I've been building my video gear and this will be great addon for it.

[FredericG]

dankers, on 10 June 2010 - 03:10 AM, said:

Fantastic!

Regarding the GPS, please see this thread on RCG:

http://www.rcgroups....d.php?t=1257119

It is a MediaTek 3329 based unit so I would certainly think the OP GPS will work with it if you change the baud rate using the MTK config Tool to change the OP GPS to match the ET one.

Hmmm... Do you have an OP GPS yet?

Thanks, so

Quote

* baud rate: 38400, N, 8, 1
* messages: GGA(1hz/5hz/10hz), GSA(1hz), RMC(1hz/5hz/10hz)

Yes, I have an OP GPS.

In the past I have also used GpsFreed + to generate NMEA from my PC. When I inject a known and stable GPS position, it is easier to find how it is encoded in the message to the OSD

Frederic

[FredericG]

Sambas, on 10 June 2010 - 05:17 AM, said:

Cool, I just ordered ET OSD (Hoppyking sale 32.50$) I can help you when it arrives. I've been building my video gear and this will be great addon for it.

Good! You are lucky, when I wanted to order it was out-of-stock and I ordered directly from ET. The package was stuck in the Belgian customs for a week and they charged 60  Euro

I suppose you did not order an eLogger? This means that we will have to find out how the configuring works (the osd is configured trough the eLogger and without configuration it will not display anything). But that is OK, the weather is bad in Belgium

Frederic

[FredericG]

In the meantime I discovered a few more things about the 63-byte message that is sent to the OSD

• How the voltage is encoded. This is a bit strange as there is a MS and LS part at very different parts of the message
• How the GPS status is encoded
• How the GPS coordinates and altitude is encoded
• How the direction home is encoded
• The distance home is not in the message to the OSD but is calculated in the OSD, strange, why is this different from the direction to home?

I have updated the little demo-video:

http://www.vimeo.com/12438625

Frederic

[FredericG]

I had a look at the OSD configuration.

It seems the ET tool reads (OSD ---i2c---> eLogger ---usb---> PC) a big block of data from the OSD that probably contains all the configurable parameters. After the reconfiguration, the blob is written again to the OSD. This config-blob is more than 6K big !

Even without reverse-engineering of the config blob, we could perhaps create a few "standard"-configs that people who do not have an eLooger could use.
Configuring the OSD could be done by writing a config-file on the SD card that could be picked up by the OSD-driver at startup and sent to the OSD.

Frederic

[Sambas]

FredericG, on 17 June 2010 - 12:45 PM, said:

I had a look at the OSD configuration.

It seems the ET tool reads (OSD ---i2c---> eLogger ---usb---> PC) a big block of data from the OSD that probably contains all the configurable parameters. After the reconfiguration, the blob is written again to the OSD. This config-blob is more than 6K big !

Even without reverse-engineering of the config blob, we could perhaps create a few "standard"-configs that people who do not have an eLooger could use.
Configuring the OSD could be done by writing a config-file on the SD card that could be picked up by the OSD-driver at startup and sent to the OSD.

Frederic

Can you record i2c trafic? Can you record few config-blobs? Like reset defaults, enable osd, different videoformat, and maybe enable one datablock and move it around the screenslots, just change one setting each time. I should get my osd next week and I'd like to start play with it.

[FredericG]

Sambas, on 18 June 2010 - 02:31 PM, said:

Can you record i2c trafic?

Yes, I have a logic analyser and a I2C -> usb device I sometimes borrow from work.

Sambas, on 18 June 2010 - 02:31 PM, said:

Can you record few config-blobs? Like reset defaults, enable osd, different videoformat, and maybe enable one datablock and move it around the screenslots, just change one setting each time.

Yes, this is the procedure I have in mind, it just takes time. This is why I proposed to compose a few config-blocks that could could fit most peoples needs.

Sambas, on 18 June 2010 - 02:31 PM, said:

I should get my osd next week and I'd like to start play with it.

Do you mean, using it or help develop?
Without eLogger I currenlty see two issues:

• Without configuration(-blob) with OSD will not display anything.
• I currently work with version 1.15 of the OSD firmware, yours might come with a slightly older FW, might works well, but not sure

Both issues could, in theory, be solved by having a mechanism of storing the FW and config on the SD card and that the driver could send that to OSD at startup, but this is too much work for this weekend.
Perhaps there is somebody who could lend you an eLogger.

Frederic

[FredericG]

Another approach would be to write new FW for the ET OSD; it hosts a PIC controller and LC74761 chip.
That would give us complete freedom.

Frederic

[dankers]

If we go that far, the next logical step would be to match it with a small cortex m3 and have complete control of the hardware as well. The M3 because there is a load of code reuse as we can use PiOS code. I know the cortex m3 we use on the AHRS is massive overkill but it keeps things the same and they are not too expensive anyway: about $7. The most attractive is the new value line of STM32s, still overkill but around $4 each.

Honestly, for the saving of $3, it is *much* easier for me to use the same STM32 as in the AHRS. Yeah, we would look a bit dumb using the STM32F103CBT6 to control an OSD, but it has room to grow and if we break out a serial port, it can be used as a very low cost FPV OSD used on its own with a GPS as it will have the power to parse NMEA its self.

What's the cost of the LC74761M can't be that much either can it? Likely more than the STM32 though.

Anyone feel like doing a board for the STM32F103CBT6 and the LC74761M? Perhaps their is a better solution than the LC74761? It seems fairly old. There is also the MAX7456 as well but this is not so cheap.

[FredericG]

Sure, if we our own board, we need an STM on it. A very popular OSD chip is the MAX7456 OSD chip, lots of code for it floating around

[dankers]

I agree, the MAX7456 is the way to go for sure, very flexable. Sanyo have a fair few but the MAX is more popular and more flexable but also $27.

My question is: What do you want to do? You are decoding the ET OSD, how far along is this? Should this be completed first? It is a good, cheap option for OP users.

Making our own board will need time, money and more effort. However I think it is something we should do at some point, I had a look around and there is nothing decent about, one cheeky bunch even call themselves the poor man version then charge $120 for a board with the MAX and a AVR! Worse it is closed source and no schematics available. If we use the MAX and the STM32, then sell it at cost we are looking at around $50 for something with the better features and with a much better MCU. Of course fully open source and Free software, not closed.

I do think it is a fun project, we can reuse a lot of what we have already, even use UAVObjects to configure the OSD and save them to flash rather than the SDCard etc but I am worried it is a distraction and will remain half finished. Commiting to making the hardware is expensive and if it never gets a good following or level of developers, it is a total waste of money.

FredericG, on 19 June 2010 - 11:43 AM, said:

Sure, if we our own board, we need an STM on it. A very popular OSD chip is the MAX7456 OSD chip, lots of code for it floating around

[Sambas]

If we get ET OSD working with little effort that should be enough for now.

When my osd arrives I need config-blobs, few raw blob samples in some readable format are just fine, and then I'll try to decode interesting parts out of it. I guess ET config software sends configs for all ET devices (addresses) in one config-blob? Does ET software have read configs from devices feature? Recording that could also be useful.

[dankers]

It would be much easier if you ordered a logger v3 as well

I agree, the ET is good enough for now, its $40 and although we will have some messing about getting it configured it is a lot less work and faster than our own version especially when I have JTAGs and AHRSs to make. The OP board can provide all the key data:

Distance to Home, Home Arrow, GPS Altitude, Ground Speed, Course, Pack Volts, Amperage draw, Barometric Altitude,  Climbrate,  Variometer and Temperature.

If we do our own later we can display an horizon from the AHRS and other cool things. Honestly after flying many hours of FPV, all I need to know is the very basics: Which way home and how far and the pack voltage. I personally find too much information gets in the way but that could be just me.

Sambas, on 19 June 2010 - 01:04 PM, said:

If we get ET OSD working with little effort that should be enough for now.

When my osd arrives I need config-blobs, few raw blob samples in some readable format are just fine, and then I'll try to decode interesting parts out of it. I guess ET config software sends configs for all ET devices (addresses) in one config-blob? Does ET software have read configs from devices feature? Recording that could also be useful.

[FredericG]

dankers, on 19 June 2010 - 12:30 PM, said:

My question is: What do you want to do? You are decoding the ET OSD, how far along is this? Should this be completed first? It is a good, cheap option for OP users.

• The main features are working. I need to do a bit more testing and a test-flight. The data-message to the OSD does not have many unkowns any more.
• I think I know how to read/write the config-blob. I not know anything about its structure yet (apart that the first 4 bytes seem to contain the SW version). I have been wondering if this "config-blob" is not the SW??? In the beginning we can treat it as an opaque blob copying it from one device to another. To reverse-engineer this blob in an efficient way, I think one needs an eLogger.
• I do not know anything about SW updates yet

Yes, lets finish the support for ET, it is as good as done anyway.

As we speak, I am trying to read the config-blob and store it on the SD card.

A limitation will be that the OSD does the home-calculation by itself. It means we cannot give directions to waypoints, only to home. The home-arrow is not very sexy


Frederic

[FredericG]

Sambas, on 19 June 2010 - 01:04 PM, said:

I guess ET config software sends configs for all ET devices (addresses) in one config-blob?

That's not my interpretation. I have been looking at the I2C communication between eLogger and OSD and the eLogger and this is IMO, a 1-to-1 conversation

Sambas, on 19 June 2010 - 01:04 PM, said:

Does ET software have read configs from devices feature? Recording that could also be useful.

Not sure what you mean?

Frederic

[PT_Dreamer]

Could you please explain to me what you are trying to acomplish with this? Is it to avoid using a dedicated datalink between GroundStation and UAV? I tought XBee Modems were not that expensive.

[dankers]

OpenPilot is a very flexable peice of hardware, this is more for people  that want to fly and use a camera to search for things and get telemetry that way. It gives them a  very cheap option to do this and I think the key point to mention is  OpenPilot is a Quad project as well as fixed wing. Besides the UAV aspect OpenPilot will be a very good (I expect it will be the best) Quad platform, a lot of people fly Quads FPV so having an OSD is important. Adding this support means this feature is there for people if they just buy the ET OSD, they don't need all the expensive ET add-ons but use the OP board to drive it. It really is a very nice feature and very worthwhile, users can add a OSD to OpenPilot for just $40!  

It is also a clean solution as well, the other stuff that is AVR driven seems to be a real mess with seperate GPS units for the OSD and Autopilot or trying to share them (really!) and all sorts of messing around, it's ugly and expensive. But with OpenPilot you just plugin the ET OSD in to the OpenPilot board and you are all set! Clean, simple, elegant and cheap.

[FredericG]

PT_Dreamer, on 19 June 2010 - 03:45 PM, said:

Could you please explain to me what you are trying to acomplish with this? Is it to avoid using a dedicated datalink between GroundStation and UAV? I tought XBee Modems were not that expensive.

In case one does not want a "complicated" ground-station with PC for example.
As OP is not flying yet, I am still flying MK and i want and OSD for my MK; in the process I work on OP components and the OP platform gets tested.

See http://forums.openpi...facing-with-mk/ for an overview of what I am working to

Frederic