element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Amphenol
  • Products
  • Manufacturers
  • Amphenol
  • More
  • Cancel
Amphenol
Forum How does Tx Only Serial Communication Actually Work?
  • Blog
  • Forum
  • Documents
  • Events
  • Leaderboard
  • Polls
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Amphenol to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Verified Answer
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 21 subscribers
  • Views 4337 views
  • Users 0 members are here
  • serial communication
  • ydlidar
Related

How does Tx Only Serial Communication Actually Work?

Sean_Miller
Sean_Miller over 5 years ago

I have a YDLidar X2 device that I found doesn't actually have a Rx line.  By design, it has no wire on the connector and doesn't expect any commands to be sent to it.  It just continuously transfers out its packets representing the state of its sensor.

 

I hadn't realized it until today that every project I've ever done with serial was by me sending a command and awaiting a response.  It was so intuitive, I never thought how the bits where banging.

 

So, my question is - does such a device that has no Rx line somehow fill a buffer and pause until bytes are read by the user or is it just pulsing and not caring what's happening on the line?

 

If it does pause, what gives the flag that it is good to continue?

 

If it does not pause, how in the world does the receiving device know how to sync up with the bits streaming?

 

Or, does serial protocol actually use the Tx line alone as a bus to talk back to coordinate the transfer of data from the transferring device?  If not, I would think it would create nothing but garbage if it started listening at a random time.

 

Thanks,

Sean

  • Sign in to reply
  • Cancel

Top Replies

  • neuromodulator
    neuromodulator over 5 years ago in reply to Sean_Miller +5 verified
    Because you must know the timing (Actually there are timing algorithms too, but thats more complex). I recently implemented an UART receiver on my FPGA, so if you understand Verilog and have an FPGA I…
  • Sean_Miller
    Sean_Miller over 5 years ago in reply to neuromodulator +5
    Thanks so much! It finally clicked for me. I have trouble thinking in such small fractions of a second, but if I envision that chart scaled out to minutes, there is no doubt I could write a routine to…
  • neuromodulator
    neuromodulator over 5 years ago +4 suggested
    When the line is in idle its at 1, when it begins transmitting goes to 0 (start bit). The falling edge indicates the beginning of a byte transmission. So unless the transmitter is sending data at full…
Parents
  • neuromodulator
    0 neuromodulator over 5 years ago

    When the line is in idle its at 1, when it begins transmitting goes to 0 (start bit). The falling edge indicates the beginning of a byte transmission. So unless the transmitter is sending data at full speed, its straightforward to synch to the transmitter, as the line cant stay high for 10 or more time units, unless its in idle.

    • Cancel
    • Vote Up +4 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • Sean_Miller
    0 Sean_Miller over 5 years ago in reply to neuromodulator

    In I2C, you have the clock line to keep the beat and compare against.  With serial, how does the receiver know a zero since the edge already fell?

     

    -Sean

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • neuromodulator
    0 neuromodulator over 5 years ago in reply to Sean_Miller

    The simple approach for 8n1 is to wait for 10 or more time units that line is high. That will tell you that the line is idle. At that moment you wait for falling edge (start bit) wich will tell you that byte transmission will begin.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
Reply
  • neuromodulator
    0 neuromodulator over 5 years ago in reply to Sean_Miller

    The simple approach for 8n1 is to wait for 10 or more time units that line is high. That will tell you that the line is idle. At that moment you wait for falling edge (start bit) wich will tell you that byte transmission will begin.

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
Children
  • Sean_Miller
    0 Sean_Miller over 5 years ago in reply to neuromodulator

    So, when it falls low and signals the start bit, I picture that it will then a series of highs and lows.  Without a clock line to index each bit, how does the 8 bits of the byte about to transmit get received without getting confused when you have two Highs in a row or two Lows in a row?

     

    Thanks,

    Sean

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • neuromodulator
    0 neuromodulator over 5 years ago in reply to Sean_Miller

    Because you must know the timing (Actually there are timing algorithms too, but thats more complex). I recently implemented an UART receiver on my FPGA, so if you understand Verilog and have an FPGA I could share it with you. Usually algorithsm work kinda like this.

     

    you run a clock at say 16 times the speed of 1 bit duration. So for instance if you plan to receive a signal of say 2400 bps, you need to sample at a rate of 38400. Here is an example of a signal 8N1 (8 data bit, no parity bit and 1 stop bit).

     

    image

     

     

    So you once you detect a falling edge, you will wait enough time to sample right in the middle of the bit1 and then bit2, and so on. If you want the receiver to be more robust you may want to sample multiple times every bit in order to avoid that transients corrupt your data. In the best case scenario a transient would just corrupt a single or very few samples from the bit. So for instance if you sample 5 times every bit, its likely that if a transient occured, it would flip just 1 or very few samples out of the 5 in total. The transmitter and receiver could use different clocks, and there could be a mismatch in their timing, but that shouldn't be an issue if you continuosly resync the clock.

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • Sean_Miller
    0 Sean_Miller over 5 years ago in reply to neuromodulator

    Thanks so much!  It finally clicked for me.

     

    I have trouble thinking in such small fractions of a second, but if I envision that chart scaled out to minutes, there is no doubt I could write a routine to poll the signal in all kinds of ways and feel confident I captured the timing of the highs and lows correct.  It's just that computers now for decades can perform such a function at freaky fast speeds with confidence.

     

    As you state, the width of each expected pulse gives room for error when you target the middle.  Any rhythm or speed differences between the two device clocks will be reset after the 8th bit of each byte preventing drift over time.  It's really genius and so darn simple at the same time.  I love it.

     

    Thanks so much for helping me get over the hump on this one.

     

    -Sean

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube