send an ASCII value using Hterm

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello im using a IR transceiver module(TFDU4301) and trying to send an ASCII value using Hterm software. It shows me error when sending any value which i am not able to figure out. I also checked with the voltage and baud rate and they seems to be ok(i guess). Can anyone please help me to find out the issue? Im also attaching a screenshot of my Hterm window. 

 

 

Thanks in Advance! 

Attachment(s): 

Last Edited: Fri. Apr 27, 2018 - 02:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As with all wireless modes, it is not as simple as sending raw data, due to signal strength changes, or drop outs, noise, reflected signals, etc.  

You will need some protocol to handle all of these conditions and mitigate their effects. 

It could also be a hardware issue, post your schematic if you want a freak to review it as well.

A picture of your setup will also help. 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

To add to what Jim said, the corruption there looks like it could also be mismatched baud rates.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This doesn't seem to have anything to do with the topic of the original, 14-year-old thread - "How to send a NUL from Hyperterminal"

 

Split?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

With this device, I doubt it is a simple as hooking it up to a serial port. Firstly you need to conform with irda timing and then add a protocol to have a preamble, packet and error detection.

The AVR usart doesn't do irda timing, so you either need to bit bash the data or add extra hardware to create the correct timing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

elma wrote:
Hterm software.

This: http://www.der-hammer.info/terminal/ ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

 

Thank you for all your replies. Meanwhile i tried to make some progress. In the Hterm window when sending any value from transmitter side a window pop up(when clicking on Asend button). I changed the Repetition to 1000 and delay to 1s. After making this change i noticed a variation in the recevier side. It started to print the raw data after a couple of transmissions. But im not able to figure it out. Im attaching the screenshot window. Any helping hands are highly appreciated.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ki0bk : I am attaching here the manual of infrared module(TFDU 4301)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

elma wrote:
It started to print the raw data after a couple of transmissions
Then it sounds like a framing issue. Try leaving a small gap between each character (or sentence) that you send. UART works by seeing a line that is quiescent then all of a sudden a start bit comes along and that triggers the received bit detection process. If you flood the line with back to back characters it may be tricky for the receiver to "see" the start of a new frame if the detection comes into the middle of an already active stream of bits.

 

One thing definitely worth trying is to configure the transmitter for 2 stop bits instead of 1. That effectively leaves one extra bit time between each framed character.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson: thank you for the reply. I dont understand the idea of  "If you flood the line with back to back characters it may be tricky for the receiver to "see" the start of a new frame if the detection comes into the middle of an already active stream of bits". Could please make it clear?. And i changed the stop bit from 1 to 2. This time i got a lengthier output when compared to other attempts.

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A UART is just a wire with 0's and 1's in it. If a transmitter is merrily pumping out characters then the 0's and 1's are wiggling up and down all the time. Now the transmitter could send 1 character (which usually means 8 bits of date and 3 bits of "framing" ) and then stop and wait for a while. So the line might look like

 

111110101101010011111111011010101111111011101111
     ^                  ^              ^

If a receiver starts to "listen in" to this then the position of the start bits is fairly obvious. There's relatively long sections of "waiting" (line just stays at 1) followed by the 0 each time which says "start bit". So the receiver can easily synchronize reception. But if I now reduce all the "quiet bits" to just 1 bit between characters the data looks more like:

1010110101001011010101011101111
 ^           ^        ^
      ^

That is the same information being conveyed but now consider what happens the receiver starts to listen in at the point I marked with the red ^. It is much more difficult to see where the frame boundaries are. So if the receiver listens in "mid conversation" it cannot spot the boundaries between one character and the next so easily.

 

So, like I say, change the transmission system so it leaves a bit of a gap between characters. In fact rather than trying to get the software to "auto send" the text "hello" over and over (something it will presumably try to do as fast as possible?) then just type the text yourself. Because humans are slow as you type h-e-l-l-o you naturallly leave a gap between the characters as humans (well most) cannot "burst type" and generate the characters so fast that there are no natural gaps between them.

 

PS and just to say that my representation of the 0's and 1's on the line above is NOT an exact representation of what happens on the line. To be honest I can't remember if the line "idles" at 1 or 0 (though I'm pretty sure it is 1) and apart from a 0 (well simply a change) to create a "start bit" I did not count my bursts of 0's and 1's after each. I just typed random 0's and 1's to represent what might be happening. The key point is that it's just to show how difficult it is to spot frame boundaries the closer the characters are together.

Last Edited: Tue. Apr 24, 2018 - 09:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps this Serial Communication  tutorial will help:

 

https://learn.sparkfun.com/tutorials/serial-communication

 

 

EDIT

 

Some pictures from there  illustrating what Cliff just said:

 

 

clawson wrote:
the transmitter could send 1 character (which usually means 8 bits of date and 3 bits of "framing" )

Serial Packet

 

But if I now reduce all the "quiet bits" to just 1 bit between characters the data looks more like:

1010110101001011010101011101111
 ^           ^        ^
      ^

 

"OK" Packet

 

 

Note how it's so much easier to follow when the pictures are actually in the post - see Tip #1 for how to do this.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Apr 24, 2018 - 09:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

Thank you for the great support and information given by all the freaks regarding IR transmission. Right now I am heading towards another concept, when i have gone thorugh the below website:

http://www.societyofrobots.com/electronics_irda_tutorial.shtml

 

The most important info from this is:

"The IrDA transceivers understand only IrDA standard signals. The UART does NOT transmit IrDA standard signals, it transmits TTL. As a solution, you also need a TTL to IrDA encoder/decoder converter.“

 

Can i use a Atmel SAMD21 Board as an encoder/decoder as suggested in the tutorial?Is it possible? If yes could anyone please help/guide me for the same?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

elma wrote:
The (sic) UART does NOT transmit IrDA standard signals

Note that some microcontrollers do have a UART with an IRDA mode.

 

You haven't actually said yet what microcontroller you are using.

 

Can i use a Atmel SAMD21 Board as an encoder/decoder

check first if it actually has an IRDA mode ...

 

SAM questions should go in the SAM forum: https://community.atmel.com/atmel-smart-arm-based-mcus

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I seem to recall someone mentioning the fact of irda timing in #5.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@awneil: I have just gone through the below link  https://cdn.sparkfun.com/datashe... (from page no:448).  Does that make any sense? How can i program IrDA in atmel?

sorry that i am posting SAM related queris here since i didn't get any reply/help from  https://community.atmel.com/atmel-smart-arm-based-mcus. can anyone please help me? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ASF supposedly has support for the irda modes for the sam d21. The problem is irda is effectively dead - bluetooth has supplanted it, so there’s not going to be much uptake of it. Put it this way, if its not done on Arduino, then its not popular. This means you’re going to have to do most of the footwork.
My suggestion would be to start with the microchip mcp xxxx parts that do the irda interface conversion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@ Kartman: Thank you for the reply. But i desperate to hear that sam d21 cannot do much with IrDA. I just came across some posts in https://forum.arduino.cc/index.p...

I am really excited to make it work in sam board, but i couldn't find any related documents or videos crying

 

But i am ready to try it on some microchip(preferably MCP2120). Could you please help me with the hardware set up of the same?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can’t really help with anything specific as i last touched irda nearly 20 years ago and tossed out a hp irda dev kit recently as it is obsolete. There seems to be some stuff on the interwebs, so get Googling.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the datasheet, the sam d21 sercom modile in usart mode can encode and decode irda up to 115200 baud. I burned my mobile data to download the datasheet. As mentioned, ASF supposedly supports this mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@kartman: sad to hear that your mobile data is drained outfrown. As said "ASF supposedly supports this mode", but i couldn't even find out an example project in atmel studio

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

elma wrote:
i couldn't even find out an example project

As noted (a number of times), "nobody" uses IRDA/SIR these days - so Atmel (or Microchip or anyone else) are not going to spend time writing examples for it!

 

If you insist on using IRDA, you'll probably need to look at older processors (SAMD are quite recent) to see if they still have any old examples or application notes...

 

 

EDIT

 

The SAMD do seem to share some peripheral IP with the old AVR32 - so maybe you could find something useful in the old AVR32 materials ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Apr 27, 2018 - 09:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The hurdles with the sam d21 probably arent that huge. The d21 is used by the arduino zero, so get the Arduino environment going on your chip. To enable irda mode on the serial port is a line or two of code to set the required bits in the sercom module. Viola’, you’ve got irda encode and decode. Then you need to write code to frane the data - you can’t just send one byte and expect it to work. You need a preamble to allow the received to adjust its data slicer - a stream of 0x55 normally works. Then you can send your data. You would want to add error detection to verify your rx data.