Notifications
Clear all

Help understanding combining serial communications over ONE wire.

45 Posts
4 Users
15 Likes
3,093 Views
(@davee)
Member
Joined: 3 years ago
Posts: 1608
 

Hi @inq,

  Maybe the problem is indeed  "they're embarrassed by their protocol" .. or even that they don't even have a formal protocol ... just a ramshackle set of half-baked fixes for problems... most of which cause as many problems as they fix. I obviously don't know this to be the case, but there is a strong whiff of chaos coming from somewhere... so it could be that it is too chaotic to achieve what you are aiming for.

I don't know how smart your logic analyser is, but I was suggesting a homebrew approach, fearing that otherwise you might be left decoding binary/hex patterns by hand or similar, whilst I thought, you would quickly add a bit of 'smartness' to anything you print out, to make it more user friendly. I don't what you mean by squiggles, so I haven't the faintest idea whether they are useful or not. What is their origin?

Seeing patterns in mud needs all the help it can get, in my opinion. But definitely, your call as to the 'most efficient' approach ... I am only a bystander making inane comments.

Did you get anywhere with the Mega, etc? Trying to squeeze everything onto one UART, although your aim, might be a bridge too far, at least at this stage. Could you achieve what you want to do if your ESP8266 had two UART ports?

And I naively presume there are 'ready to fly' mixes of kit which actually do at least the equivalent conversations ... do you have access to any such combination, that you can eavesdrop on?

Sorry, these questions sound totally naff, but as I said a while back, this commercial radio control kit is fantasy land for me. I understand you would like to interface and utilise it ... that makes sense ... but I don't know what the existing 'out of the box' stuff does. I am struggling to find something that doesn't evaporate before I can get hold of it.

Best wishes, Dave


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

@inq Is this any help https://www.multi-module.org/using-the-module/protocol-details/flysky-afhds2a

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.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


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

@zander,

Thanks, but no... that seems to be mainly about the communications between the transmitter and receiver.  It referenced the iBus protocol, but the links went nowhere.  It does remind me of an option.  Apparently I can overwrite the whole system with OpenTX... like putting replacing Windows with Linux.  That might be a last resort option, but I'd like to keep it stock as most people that might want to use what I find out... probably won't be as proficient as people on this forum.  

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

Maybe the problem is indeed  "they're embarrassed by their protocol" .. or even that they don't even have a formal protocol ... just a ramshackle set of half-baked fixes for problems...

I believe they sell some dedicated sensors that can send back data.  The list is pretty short and I've never heard of anyone that actually uses it.  I've not looked, but I've not heard of any 3rd party sensors using it.  Maybe they have backdoored knowledge to keep it to themselves and all on the Internet are just reverse engineering it like I'm trying to do.  Although... that FAQ statement sounds like they are willing to part with a spec.

Posted by: @davee

I don't know how smart your logic analyser is, but I was suggesting a homebrew approach, fearing that otherwise you might be left decoding binary/hex patterns

https://www.saleae.com/ - It'll decode the bits and give me the hex data.  Squiggles - "The overshooting harmonics an oscilloscope shows on a square wave."

Posted by: @davee

Did you get anywhere with the Mega, etc? Trying to squeeze everything onto one UART, although your aim, might be a bridge too far, at least at this stage. Could you achieve what you want to do if your ESP8266 had two UART ports?

Well at the moment, I only need one port as I'm not monitoring the Servo side.  The only thing the Mega showed me was that it runs slower.  It's 16 MHz and the ESP8266 is 80 or 160MHz and since my Admin library doesn't run on the Arduino, all I can get is serial debugging and at messages coming out a 7, 3 and reflected instantly, the output becomes a indecipherable  mess because of my lack of patience. 😆 IOW... it's a lot easier when I can filter dynamically with my Admin front-end.

Posted by: @davee

Seeing patterns in mud

... is quite appropriate, especially since some of those patterns are my own messages making ripples in the mud... their messages, spawn my messages, which combine with their messages and I'm replying to my own replies.  Can you say hall of mirrors? 🤪 

Posted by: @davee

I understand you would like to interface and utilise it ... that makes sense ... but I don't know what the existing 'out of the box' stuff does.

I don't have it.  It's expensive and limited. "https://www.amazon.com/Flysky-Telemetry-FS-CEV04-FS-CPD01-Transmitter/dp/B01FJX3DR4/"... when I can use a $3 ESP8266 and one resistor and get LiPo voltage sent back.  Add another couple of bucks and get airspeed, attitude and RPM, accelerometers, gyros, GPS.  I've got some free GPS units coming on the slow-boat from China (Banggood).  Maybe add an ultrasonic sensor and have automatic landing system.  It's all big fun combining RC plane with robotics.

 

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


   
Inst-Tech reacted
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1608
 

Hi @inq,

  Thanks for the reply.

  I confess I am still struggling to figure out what the Flysky 'expanded' system looks like.

 I looked at the Amazon link you provided. This seems to be 4 sensor boxes, and 1 I-Bus receiver box, which are also available separately from AliExpress.

(eg. https://www.aliexpress.com/item/1005003994617691.html)

I am a little confused as to how these play together and with everything else, especially the I-Bus box, whose function isn't clear.

-------

It seems the sensor boxes can talk individually and directly to the receiver you have, although they might need a different cable as you have the '10' receiver instead of the '6 receiver', though given they have only 3 wires, two of which I presume to be power and ground, this wire might be pretty basic. Maybe that is just a problem of the wrong plug ... do you know more about that?

======

I can obviously see why you would like your 8266's to do this directly, but given the lack of information, I am wondering if buying one or more of the Flysky boxes is a necessary precursor,  to see what the protocols are, albeit I am not clear which ones would give you enough useful information for the least cash. 

Does this seem like a viable path?

========

Sorry if the Mega trial was a distraction .. I had hoped it would reveal a bit more. Did Mellink actually achieve anything useful, or is it just an abandoned quest?

======

My impression is that you think you understand the servo data side of the protocol, but are left with two problems:

  • figuring out the sensor protocol
  • squeezing the sensor and servo data into a single UART

Achieving the second one before the first seems unrealistic, as the protocols obviously have to play nicely. This requirement might of course be wishful thinking.

If the second aim proves impossible, superficially, I presume figuring out the sensor protocol is still useful to you, even if you need to find another approach, like two 8266s or a 2nd UART in some form to meet all of your aims ... is that correct?

------

I notice mentions of OpenTx as an open source replacement, but maybe only for some of the Flysky transmitters ... I can see the obvious benefits, but no idea of the downsides.

-------

Sorry, this is meandering mess of random thoughts.

Best wishes, Dave


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

Posted by: @davee

I can obviously see why you would like your 8266's to do this directly, but given the lack of information, I am wondering if buying one or more of the Flysky boxes is a necessary precursor,  to see what the protocols are, albeit I am not clear which ones would give you enough useful information for the least cash. 

Does this seem like a viable path?

Oh, I'm getting you now.  If I get one of their sensors and put the logic analyzer, I can see the requests and replies and get a clear picture of their protocol instead of yelling into a cave and trying to interpret the echoes.  

 

Posted by: @davee

My impression is that you think you understand the servo data side of the protocol, but are left with two problems:

They come out of two different ports on the receiver and according to all the opinions on the Internet, either one or other can be used or both.  There's no dependencies.  The servo side is easy because its just a broadcast.  It doesn't accept anything so it's just pull off the packets, parse them and blow out the number to logic or other servos.  They use the same range as the servos... 1000 to 2000.

Posted by: @davee

If the second aim proves impossible, superficially, I presume figuring out the sensor protocol is still useful to you, even if you need to find another approach, like two 8266s or a 2nd UART in some form to meet all of your aims ... is that correct?

Sure.  The sensor one give me plenty of opportunities to get telemetry.  Altitude, speed, rate of climb, location, rpm, temperatures, accelerations, gyro data... etc.  And yes, I could use two ESP8266 if I have to.

Posted by: @davee

I notice mentions of OpenTx

Although, I have no intentions of making a product, I might try to give thorough instructions for the RC guys to build their own.  The simpler, the better.  For me... I'd be plain happy to get the LiPo voltage so I know when the tank is about empty.  Everyone at my field/club just uses a timer.

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


   
DaveE and Inst-Tech reacted
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1608
 

Hi @inq,

If I get one of their sensors and put the logic analyzer, I can see the requests and replies and get a clear picture of their protocol instead of yelling into a cave and trying to interpret the echoes.  

Precisely, this has been my general thought from the beginning, though sorry it has taken a few banters to understand what you had in front of you ... initially I assumed you were starting with a 'complete' commercial system, and were looking to 'extend/upgrade' half of it with your 8266 expertise and so on.

At the moment it seems much more difficult than just yelling into a cave .. as this particular cave will be expecting a particular "yell" (message), which could be quite different from the message coming from the receiver. e.g. some comms protocols have a response message which amounts to a pass/fail single bit content. If you only saw the outgoing message, with a large number of content bits, it would not be obvious that the response should be a 1 bit message. And obviously there are almost unlimited number of variations on this theme.

To simulate the messaging, I had hoped the Mega trial would have yielded some clues in that direction, but sadly that was not the case, though I confess to not being clear why ... assuming it is a'working' program, not just a failed attempt. Maybe, it would be obvious if I had it in front of me? (I understand the Mega is a lot slower processor, etc., but presumably Mellink would have been similarly limited.)

--------

Much of my previous reply was just me recapping the position ... and I don't see any significant disagreements from you.

I think you need to get the sensor protocol firmly established, and in my opinion that means having a 'working' version in front of you to probe with logic analyser, or maybe something like an 8266 acting like a 'smart' logic analyser. That means establishing some way of 'yelling' the right responses at the right times .. buying the minimum number of bits, for a little reverse engineering, seems the most 'obvious' approach, given the lack of published information and failure of Mellink's code to yield enough insight.

--------

As for shoehorning both servo and sensor data into one 8266, I am still wondering if the switch I suggested is still a possibility? For data like battery voltage, you only need to measure it 'infrequently' .. say once per 10 seconds? Servos might need more attention, but I suggest an occasional message lost should not be a problem, providing the aircraft does not change anything. So can some kind of 'cycle stealing' approach be used?

But until the underlying protocols are understood, this is just speculation.

Best wishes, Dave


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

Good news - I have received a reply from FlySky this morning.  

Bad news - I think we're having a communications issue (English-Chinese).  The protocol they sent was only for the servo side that I have working already.  I thanked them for the reply and added clarification that I was looking for the sensor connection protocol.  I am hopeful for a better/quicker response since I'm sending it directly to the contact (and his CC's) instead of coming in on the generic contact email.

 

Keep your fingers crossed!  😉 

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


   
Lee G, DaveE and Inst-Tech reacted
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
Topic starter  

Well... so much for that idea.

Good morning,
As far as I know, our officially published ibus protocol does not support the development of sensor return.
I suggest you go to Github to find articles about the ibus protocol.
cheng
 

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: 3 years ago
Posts: 6662
 

@inq If you need 2 serials and each board has only one, can you use 2 boards and somehow get the boards to communicate in a way you can use?

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.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


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

Posted by: @zander

@inq If you need 2 serials and each board has only one, can you use 2 boards and somehow get the boards to communicate in a way you can use?

Possibly.  I think it'd be possible, but my problem is getting worse.  The GPS units that I want to eventually use also work via serial... so I'd need three hardware serial ports.  

 

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: 3 years ago
Posts: 6662
 

@inq It's probably not an answer you want to hear, but Adafruit has a USB GPS I think. There also is this, a serial mux, sorry, just googling for a friend. MUX  A higher level description is at Sparkfun even though they don't carry it anymore HERE

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.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


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

Hi Ron @zander & @inq,

  Inq, Sorry to see your 'support desk' response ... it is more than I thought you would get, but not much more useful.

Ron, there are analog multiplexer options for switching between two or more serial lines ... the trouble is, when serial messages are being received, unless the mux is pointing to the line that is passing a packet/character, then the packet will simply be lost. And if characters are being sent at pseudo random intervals, it wil be impossible to know which way the mux needs to configured at any one moment.

Sadly, adding a third source of incoming data is not going to make it any easier.

Sounds like you need some kind of serial character 'marshalling' solution ... each incoming serial line will need its own "UART" ... well "UAR" for Receive at least .. T for transmission is another story. Maybe an ESP8266 could spend its entire career being a semi-soft "multi-UAR"? Other possibilities are also plausible!

Best wishes, Dave

 


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

@davee Agh, of course, it's been a few decades. I forgot our line receivers had their own small processors and some memory for buffering. I gather nobody makes a UAR? Sorry, I hate to see Dennis get stuck, his projects are always so interesting and educational so I want to see him succeed.

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.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
ReplyQuote
Inst-Tech
(@inst-tech)
Member
Joined: 2 years ago
Posts: 554
 

@inq  I think I may have an idea of what your asking..In the industrial process control world, we used Token ring topology, and ethernet to do what your trying to do.. see link https://www.techtarget.com/searchnetworking/definition/Token-Ring

however this may very well prove to be complicated, and expensive..as you know, I'm not a network person, or know very much about the subject. My job was to install, trouble shoot, and repair/replace system hardware, sensors ( Instrumentation) and calibrate.

regards,

LouisR

LouisR


   
Inq reacted
ReplyQuote
Page 2 / 3