Notifications
Clear all

Help understanding combining serial communications over ONE wire.

45 Posts
4 Users
15 Reactions
3,398 Views
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Although the specifics of this problem may be too esoteric, I'm hoping people have done this kind of thing in-general and might be able to get me through some learning curve.  It's in multiple parts.

Part 1 - Simply Getting the Servo Data

I'm wanting to interface a FlySky remote control transmitter/receiver with an ESP8266 module using FlySky's iBus protocol.  I've studied @dronebot-workshop 's topic at:  https://dronebotworkshop.com/radio-control-arduino-car/   I've also studied several Internet resources along the way.  There are several libraries available, but they don't include support for the ESP8266.  This is largely because there is only one serial TX/RX pair and they're used for uploading sketches.  I've pretty much solved this part.  

PXL 20230329 193802805

Here is the breadboard with just the receiver.  In this first part I am simply receiving the servo messages via the red-circled cable.  The 3 wires are ground, power and simplex serial from the RC receiver to the RX pin of the ESP8266.  Here is the output as received on the ESP8266 and displayed on the browser UI.

image

Part 2 - Sending Telemetry Back to the FlySky tranmitter

I haven't seen it, but supposedly I can send data from the ESP8266 to the receiver and the receiver will return it to the handheld transmitter and can display two lines on the transmitter's LCD screen.  At the moment, I want to send back LiPo battery pack power and RC airplane altitude and airspeed.  This is done on the second pair of wires attached to the receiver above at the yellow circle.  Again, the 3 wires are ground, power and this time the one logic wire uses half-duplex.  The author of the IBusBM library (Bart Mellink) that Bill recommends has a picture showing it connected on an Arduino Mega... 

image

If I understand it correctly, the one wire from the receiver's servo side (far right yellow wire) is going to RX1 of the Arduino.  TX1 is not needed.  The one wire from the receiver's sensor side (far left yellow wire) is split with one going to RX2 and with a diode going to TX2.  I'm assuming the diode eliminates signal coming from the receiver going to the TX2 line, but allows the Arduino to send out data over this line to the receiver.

Part 3 - Only using one Micro serial port

Bart also states, "If you plan to use both servo output and sensor data in your sketch, your should use two different UART ports on your Arduino board."  Unfortunately, the ESP8266 only has the one hardware serial port.  It can do software serial, but it can cause problems with driving servos since they're using PWM from the same timer.  Anyway... with further research, I found one-reference in a forum to combine the simplex line with the half-duplex line at https://github.com/cleanflight/cleanflight/issues/2545#issuecomment-268343507

with this picture and in a later post of his, he said it uses...  "10kohm and something like 1n4148 or similar. I just scrapped some stuff in my drawers."

image

In my simplistic, cookbook mentality, I'm trying to combine these to separate topics/pictures into what I think they're trying to tell me. I think this is what I need to do, but I'm not sure.  I also did not show the logic level shifter, which I'll put in-line where the single purple line is between the diodes.

Combine

 Does this make sense to someone that knows about hardware?  

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
Quote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

  I am hoping others will rush into help, but just in case they are all on vacation or washing their hair ....

  The diode and the resistor look familiar  ... and I can imagine the ESP8266 has a UART 3.3V serial port ... but after that I am in fantasy land ... so maybe I'll just try a 'high level view' comment or two, and see if it helps clarify something.

Starting with this diagram.. let's call diode connected to receiver Dr, Diode connected to 8266 D8, and resistor R

image

Do you have enough control over the receiver to coordinate the multiplexing?

----------

Normally with logic circuits, you aim for a 'strong' signal that can reject interference, etc. ... hence it is not unknown to find a faulty logic circuit to be 'almost working' or even working correctly, in spite of a significant hardware failure. This has the feel of trying to do the 'impossible' by breaking all of the good design rules.

At first glance, it looks like at least the Servo Side Pin may need to adopt a weak pull up state to allow some of the possible talker/listener pairs to communicate, plus there is R, a 10k resistor in its path, which will also considerably weaken the strength of the signal in both directions.

... Ughhhh .. ..! 

Time to rethink this approach (IMHO) ... I had started to try to work out whether your original scheme in the diagram was possible ... on reflection, I am removing that half completed analysis, and introducing a plan B

-----------------

Do you have at least one spare, output capable, pin on your 8266?

Perhaps you can use a (time) multplexer to effectively switch the different paths?

I am assuming that you want the 8266 UART to:

  • either listen to the Servo Data,
  • or for the 8266 UART to chat both ways in a half-duplex fashion with the Sensor side pin

is that correct?

That is:

  1. There is no conversation between Servo Data and Sensor Side
  2. Servo Data and Sensor side pins are 100% polite ... they take it in turns to chat to the 8266 without trying to cut across the others turn.

(Actually, with a multiplexer, it is more likely that the 8266 will have a 'mute' button ... so any attempts at the other pin to talk or listen in will be met with silence. Of course with serial streams, this can imply receiving 'half-words', which can often be rejected, but is not good practice.)

------------

In summary ...

Do you have a spare 8266 pin that could control some kind Servo Side or Sensor Data conversation multiplexer?

If so we can discuss how it might be implemented..

Best wishes,

Dave


   
Inq reacted
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Apologies for the slow response.  I think my old 3rd generation i7 desktop workhorse bit the dust  last night and my Arduino IDE and many of my files are on it at the moment.  This might be my sign to chomp down on an AMD Ryzen 9 7950X3D machine... although the i7 gave me time to get coffee and think. 😉 

I'm not quite sure where you're leading, I like the way you think out of the box.  I'd make pins available for other things just to learn some new technique from you.  Using the ESP8266 versus a micro with 2 hardware serial ports is the priority... thus the Internet search for the obscure posting about combining them.

I've not found any official FlySky iBus protocol paper.  It seems all I've found is what people have pieced together.  I was wondering what keeps things from signaling over each other especially over the one wire with two logical serial ports involved.  From what I can see... all I can assume is that the receiver processor always keeps its out going data synchronized and at least it won't jump on each other.  Digging around, it also appears the microprocessor outgoing can't be unsolicited.  The receiver will periodically ask for things and the micro is expected to respond in a semi-synchronous type arrangement.  I have read that the servo data comes every 7 ms.  I'm assuming in-between is when the receiver's sensor side will ask for data.

I see in existing code where it pings for a sensor count and types and then periodically asks for the current values.  It's not a push process from the micro for telemetry data like altitude of the plane.

I have the servo simplex channel working.  I'm thinking I should try to first get the half-duplex side working without the servo side mixed in. 

You also keenly observed the pins I was using (D8) instead of the standard RX/TX pins on the other side.  I think I blew out the standard RX pin on my ESP8266 by not having the logic shifter and the receiver works on 5V.  I'll break out a fresh ESP8266.  Even working with half-duplex will be new to me.

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

  Sorry to hear that your PC is having a hard time ... but I guess your 3rd gen I7 has probably earnt its retirement.  At least some PC processors and memory seem to have come down in price, and whilst my SSD 'drives' are still the earlier slow ones, I note some rather quick ones at about the same price are now being offered.

------

  In principle, all I am thinking about is a double-pole double-throw (DPDT) switch which alternates the 8266 UART port between the Servo and the Sensor ports, with the 'lever' of the switch being operated by a spare pin on the 8266.  Obviously, the DPDT switch would be 'solid state' (MOSFET based, which could be chips or individual FETS), and there are a number of 'details' to sort out, not least of which includes the voltage disparity between the two units, but hopefully that is more grind of dotting i's and crossing t's, than innovation.

-------

The tricky bit, as you are already discussing, is making sure all three parties to the conversation play politely. Clearly, you can control when the 8266 participates, but the other two parties are presumably a fixed entity, so at the very least you need to clearly understand how they work and what that require. 

It seems that the RC receiver controls the timing of conversations from both the Servo and the Sensor ports, but the 8266 has only 1 'ear', so this is only possible if the RC receiver does not send from both ports at the same time ... or maybe you can find some kind of compromise, probably with the Servo which never gets any feedback, so that missing the odd packet of data is acceptable if the 8266 is busy conversing with the Sensor.

However, if the Sensor initiates its conversation, then either the 8266 must ALWAYS be listening at the start of the conversation, or maybe the Sensor retries after a timeout?

-------

I think establishing the conversation 'rules of engagement' should probably be your first priority. Even if you reverted to your magic diodes and resistors, the same rules would need to be established. A digital oscilloscope might be handy, but even without one, maybe you can set up a bench test with a processor with two UARTs to see what is happening and develop some rudimentary test code/protocol to find a compromise that only uses one of the UARTs at any one time, which can then be refined to use 1 UART and a switch.

Does this make sense?

Best wishes and good luck with your PC, Dave


   
Inq reacted
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

  As a kind of postscript, I was looking for a simple explanation of the type of multiplexer I had in mind, to put you more in the picture, but so far I haven't found one I like.

To start, note that multiplexer can refer to two different (albeit related) types of components.

---

The type you need is often called an "Analogue multiplexer" ... because it can switch analogue signals such as the input to an audio amplifier, as well as digital logic signals, and fundamentally is based on using a FET for each pair of contacts. The handy thing from your viewpoint is like a 'real switch', it allows the signal to go in both directions.

--

The other type, such as a https://assets.nexperia.com/documents/data-sheet/74HC_HCT257.pdf

consists of only digital logic, which only allows the signals to flow from input to output.

Most of the Youtube videos I found, described this type ... and even then made them look frightening, when they are just as simple to understand as say an XOR gate.

---

As a background 'warm up' try https://www.ti.com/lit/ds/symlink/tmux1072.pdf

(This is just one of several possible chips -- not a recommendatoin to purchase.)

Like all datasheets, just read the descriptive bits to get a 'flavour'.

Note that it has three pins to control the switch positions, as explained in the snip below, taken from the reference

image

That does not mean it needs three pins from your 8266 .. just one!

Connect OE to ground (L) and drive both SEL1 and SEL2 with your 8266 output pin ... when the pin is high, both switches will be in normally closed position, when it is low, both switches will be in normall open position.

----------

Also, maybe glance at https://www.digikey.co.uk/en/articles/save-space-cost-power-using-analog-multiplexers-switches

... for a more general description.

But don't get bogged down into the details ... I just wanted to show I was discussing something 'real'.

In fact, for your case, I think you could use a few discrete FETs, but the ones I have are the size of small ants with leads about 3mm long, so cheap but not very prototype friendly!

Best wishes, Dave


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

@davee,

I've gotten my development system going on my laptop.  I'm definitely going by the divide and conquer route as you suggest.  From the O.P. I had the servo coming to the ESP8266 working fine.  But it only needs the RX to listen to what the RC receiver is telling it.  That was easy.

I disconnected the servo side just to take it out of the equation.  I'm working on sensor side now.  I'm starting to get a picture of the protocol.  It is made up of 3 messages.

  1. asking if the micro wants to add a sensor N (N = 1 to 10)
  2. if #1 affirmative, it'll ask what type and data length.  There is a list of sensor type supported.  Length is int16 or int32 only.
  3. then it routinely asks for the value for each sensor.

I've got some of this kind-of working.  I've even seen my sending of voltage being displayed on the RC transmitter... so I'm close.  However, my first problem seems to be with the first message type.  It appears, I am supposed to reply in the affirmative by just echoing the same message back.  If I don't echo anything, it assumes a sensor doesn't exist.  Unfortunately, this has the problem on the half-duplex line of going to the receiver, but also coming right back into the RX line's buffer of the ESP8266.  It took many many hours to finally discover this and only through blind, dumb luck...

I disconnected the receiver completely and noted that I was still getting serial data coming in on the RX.  I'm just mumbling to myself and drooling on myself in the dark.  😆  It sure seem like the protocol should require a change in the reply so I can distinguish from what the receiver is sending me and what I just sent out.

I've been hunting the web for an official iBus protocol document.  Still no luck.  All I seem to cross are what others have ferreted out on their own... which is what I'm doing.  

I probably should break out an UNO and use Bill's recommended library and just inspect to see how it is working with the assumption he got it working fully.  Bill only used the servo side in his video.

VBR,

Inq

 

 

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

   Good to see you have made some progress .. this looks like one of those protocols that has been designed by somebody who likes making everything as complicated as possible.

A few seconds Google also showed some Arduino Mega stuff on Github which is presently using three wires ... I can see now it is the same B Mellink code ... I guess that is what you been inspired by, but are trying to make it do it with just 1 UART, to make it more 8266 friendly. Certainly, in your position I would start with the Mega,.. but then I just happen to have a Mega .. but absolutely no FlySky stuff.

You say "I disconnected the receiver completely and noted that I was still getting serial data coming in on the RX. "  ..... which I didn't understand.

Assuming you have the 1 diode to block receiver fighting TX, and link to Rx wire, It is obvious that the 8266 RX will see all that Tx sends, and need to disregard it (or maybe even check it).

Then presumably the receiver sends sensor response, which Rx will also hear.

I presume it makes more sense when you can see what is going on ...?

--------

I just had a quick look at the GB Mellink code .. not that massive in length, but somehow it seems to include both sensor and servo together ... is this me just misunderstanding the words?

Its too late in my (UK) day to track any more, but I am not clear if there is just one instance of that code or maybe two instances to cover all three pins in the Mega setup.

I don't understand why the servo and sensor stuff is mashed together ... if it is?

----------

Sorry, not sure I can offer much at the moment, except good luck wishes.

Best wishes, Dave


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Posted by: @davee

Assuming you have the 1 diode to block receiver fighting TX, and link to Rx wire, It is obvious that the 8266 RX will see all that Tx sends, and need to disregard it (or maybe even check it).

Then presumably the receiver sends sensor response, which Rx will also hear.

I presume it makes more sense when you can see what is going on ...?

Yes, I have the one diode in the circuit to protect receiver output from going to the TX pin...  

PXL 20230403 105558723

... so it is the same as this, but without the servo link wiring.

image

Posted by: @davee

I just had a quick look at the GB Mellink code .. not that massive in length, but somehow it seems to include both sensor and servo together ... is this me just misunderstanding the words?

No... you are correct.  It is as if he was planning on using the only one serial port, but couldn't get it to work.  In his verbiage, he mentions we shouldn't use a 1 port design... implying that someone else does.

Although the code does have both servo/sensor all in the same loop method, in use, he actually uses two instances of the class... one for servo side and one for sensor side.  At the top of his loop method he has a linked list to give each instance some CPU time. 

He also has some timing code (< 3 ms) so he can ignore the data he just sent out.  

My code doesn't have the linked list, nor the timing code.  I'll upload it, but it's not presentable at the moment... still hacked together. 😉 

I have errands today, but hope to get back to it tomorrow.  I'll break out the MEGA and see what it does.  

VBR,

Inq

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

My laptop, although newer i7 generation, never has run near as well as my "slower" desktop.  I think it has a spinning disk inside although it's dead quiet.  I have 16 more GB of memory and a 1TB of SSD coming.  They were on sale - "https://www.amazon.com/gp/product/B07MFZY2F2/"

Seems like computer stuff is dirt cheap.  $90USD for this... I remember paying $800USD for a 10MB harddrive... just a blink ago. 🙄 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

 Good to hear you are making progress ... I think connecting it to a Mega and just watching how it works is an important step on the learning curve. You might also want to hook up a separate serial listener or two, to eavesdrop on the communications, if you have a spare 8266 which can write to a screen, or may be a file of some type.

If Mellink couldn't get a simple serial port to work, then that suggests that either it is impossible, or a new approach is needed. My concern is that both the servo and the sensor outputs insist on talking at the same time time, but maybe that can be made acceptable if one can be ignored, and the message picked up on a resend?

---------

Laptops did indeed have spinning disks until (maybe?) 3-4 years ago .. but they can often be swapped out for an SSD, which can make a big difference to a laptop that has lost its initial 'sparkle'... sometimes easy to do, other times you have to prise the main case open, but my limited experience is that it is more scary than difficult... though I do not accept any liability!!

If you do fit a new drive to any Windows box, I suggest you do a 'new' installation ... you may need the Win installation license number, but in many cases it will find it automatically. There are free programs on the web that can tell you what it is on a working machine before taking the old drive out.  (I have used produkey before .. some anti-virus programs flag it, because it can be used for pirating software, but so far as I have read (no liability accepted), it is legitimate ... only that some of the uses it can be put to are not ... which applies to lots of things in life.) Obviously a new installation means reinstalling programs, data, etc. but it helps to clear out the detritus as well. 

To find out what is fitted without surgery, if it is Windows box, try using Windows to tell you..

Under Windows (10), I found the disk model number listed by following the path

 System Information ->Hardware Resources->Components->Storage->Disks ..Model

Then see if Google can find that model number ...

Bear in mind that laptops often have the 'laptop' version of a processor ... ie a version that is limited on the amount of power it takes, and hence the amount of heat it has to dissipate. Desktop versions of the processor, especially Intel, are often rated in the 100+ W range, laptops maybe 15W. Similar decisions apply to the GPUs, although obviouly some programs make little use of the GPU 'crunching' power.

-----------------

Good luck, Dave


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Update...

Fixed the desktop.  It turned out the monitor was the problem.  Just un-plugging waiting a minute or two to let it bleed off and restarting fixed it. Who knew? 🙄 

Upgraded the laptop 32GB, M.2 SSD 1T.  The memory speed only went up about 12%.  I thought these things used some interleave type process and that adding a duplicate module would increase speed.  I remember my desktop wouldn't even allow you to put just one module in.  At least I have some analysis programs that will use the full 32GB, so its not really wasted.  My laptop will now be my number cruncher. 😉 

I've always thought I had an SSD in my laptop.  It was dead silent and a casual glance said it had an SSD.  BUT... it turns out it has some hybrid Intel Optane / HDD drive pairing thing.  Anyway replacing with the M.2 drive, the benchmark went from 2209 (16th percentile) to 24321 (90th percentile).  Now it feels like a totally different system.

Back to topic at hand...

I keep getting inconsistent results.  I've seen three sets of values going to the transmitter and simply re-compile and only one will show up.  Looking at the data, I don't even see the request coming in for the 2nd and 3rd sensor.  It really seems like a quirky API.  The fact that it has to ask for each sensor being enabled (up to 10) and the expected reply is simply an echo of the request is non-sensical in half-duplex system.  The Mellink code uses some kind of 3 ms threshold - if a message shows up that is less than 3 ms from the last, it throws it away assuming it's the reply it just sent out.  If the receiver doesn't get the first reply, it doesn't send out the request for the second sensor's existence.  

I found on the FlySky website their FAQ.  On it, it says...

33. How can I get more product information?

  • If you need more information Flysky products such as schematics (limited open source products), component model numbers, certifications, ibus information, etc., you can send us an email with the subject of the message clearly indicating the needs and uses.

I sent a request... asking for the protocol's definition.  I'm surprised, I can't seem to find anything official anywhere.  I'm not holding out a lot of hope.  It's been 3 days... no word yet.

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 4 years ago
Posts: 7195
 

@inq I have the FlySky on my Amazon wish list. Not sure what I will do with it, but it seems like a potent controller, so I will follow your progress with some interest. Please keep us informed.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1728
 

Hi @inq,

  Cheap fix with the desktop! I have seen my 'homebrew' desktop get into a bit of stew a couple of times that needed a complete power down, jump up down five times, then power up again, but I'm not clear which bit of the chain was the ringleader.

I am not surprised by your speed findings relating to both the memory and the drive. PC level processors have so many caches and tricks to keep the number crunching centre busy, the external memory speed is no longer the only speed determing point. Having extra memory may also help stop it 'paging, when it is using the disc drive as additional memory 'parking' area, but that will show up when memory is getting 'full', not neccessarily in a memory test.

As for the quirky results, it is definitely hard to visualise what is happening.

Half duplex means the same wire has both local and remote transmitter, plus local receiver, so the local receiver will see the local transmitter .. I am unclear, which of these the 3ms threshold code was trying to lose.

I saw the 3ms threshold when I glanced at the code, and it gave be a bit of a queasy feeling ... had it been a case of send and immediate readback, possibly to check the message wasn't mangled, as well as to 'consume' it, I would have been more comfortable, but 3ms window..?

Perhaps it makes more sense if you can actually see it happening .. but maybe not ?

-------------

I don't know how far you want to take this? but I can imagine that my approach would be to either further 'document' the protocols ... or drop the whole project if it had got too tedious. I wonder which way you are thinking.

----------

How tricky would it be for you to make a kind of "UAR(t not needed) oscilloscope" ... ie a spare ESP8266 (or other) eavesdropping on the UART line, and simply recording, with time stamps, all of the traffic?

Ideally, the time stamps could be matched to anything you can see on the 'system', possibly by having a hardware line to synchronise Time zero.

Even more ideally, it would electrically figure out which port sent it, but that needs some hardware skullduggery .. possible, but not a no brainer... so start 'simple'.

Just to get a view of what the traffic really looks like? This would independently show whether the Flysky changes its mind.

Did you mention that multi-million dollar opportunity when they shared their protocol ... No? ... maybe I am not betting on that amounting to much either then, but sometimes life has surprises...

Of course, if they reply with really useful information, it might be with an NDA proviso, whereas if you want to publish, they have much less leverage if you report what you have independently discovered.

Best wishes, Dave


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Posted by: @zander

@inq I have the FlySky on my Amazon wish list. Not sure what I will do with it, but it seems like a potent controller, so I will follow your progress with some interest. Please keep us informed.

I've had the FlySky for some time when I was messing with RC airplanes.  I gave it up because of crashing a plane that took weeks to build and multiple hundreds of dollars.  Also cracked the fuel motor.  I've picked up the habit lately because you can buy whole electric motor, controllers and props for about $20US and because on FliteTest.com you can download plans for free of foamboard based planes that you can build in a day for about $5.  I've crashed quite a few... but it doesn't hurt like it did before.

In robotics, with Bill's tutorial it makes sense if you want to control a robot manually.  And if I can mesh the two hobbies... it's just fun.  Getting servo and telemetry to/from the ESP8266 opens all kinds of projects on the airplane... robotics, autonomous planes...  

At the moment, the servos side seems solid... the telemetry side... not so much.

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Posted by: @davee

I saw the 3ms threshold when I glanced at the code, and it gave be a bit of a queasy feeling ... had it been a case of send and immediate readback, possibly to check the message wasn't mangled, as well as to 'consume' it, I would have been more comfortable, but 3ms window..?

Exxxactly! 😉 It's gone further with me... it gives me gas. 😆 

I'm pretty used to PC serial communications, but it's always been full duplex.  The fundamental idea to ask for each sensor... "are you using 1", "are you using 2"... and the answer I'm supposed to reply is just the echo.  Seems idiotic in a half duplex scenario through one wire.  The fact that there is NO official listing of the protocol... even by someone that leaked it on the Internet, blows my mind.

Sure... the 3ms window should allow you to ignore your own replies.  But I've seen all kinds of timing variations coming from the receiver.  Some of them are less than 3 ms between packets retrievals.   It just seems to lack any respectable robustness.  Even Mellink mentioned "issues" with the sensor side... although he seemed to feel it was attributed to trying to combine the servo and sensor into one port.  I think it's more likely to be a poor understanding of the protocol on our parts.

Posted by: @davee

I don't know how far you want to take this?

I've tried replying with different things... no CRC, reply only to the first instance of a sensor #.  The thing continue to ask on every cycle... are you using 1... etc.  It's not a one time deal.  It appears that it is ALWAYS

  1. Are you using sensor 1? - Reply
  2. What is sensor 1 type/size - Reply
  3. What is its value - Reply
  4. (same for next sensor) - If there isn't another sensor, don't reply.

AND... it does this routinely.  Not once at boot up.  A very crude and frustrating API!!!

I've run out of ideas to try.  I'm hoping I'll receive a real protocol standard document from FlySky.

Posted by: @davee

How tricky would it be for you to make a kind of "UAR(t not needed) oscilloscope" ... ie a spare ESP8266 (or other) eavesdropping on the UART line, and simply recording, with time stamps, all of the traffic?

I have a logic analyzer... or does your thought include/require all the "squiggles"?  What is your thinking?  I'm getting all the data and displaying it in my output now with timing... without the logic analyzer.

Posted by: @davee

Of course, if they reply with really useful information, it might be with an NDA proviso, whereas if you want to publish

Much of their stuff is open source already.  I can't imagine, they'd really care, but then again, why isn't already out there.  Actually, I think they're embarrassed by their protocol and won't let it out of the lab. 😆 

VBR, 

Inq

 

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
Page 1 / 3