1, is ttl same thing as serial?
2, can I use this usb-ttl's tx and rx pin to upload sketch to my standalone new avr mega8 chip?
3, I have an uno. Can I use the above usb-ttl to talk to my uno? how?
arduinomagbit:
1, is TTL same thing as serial?
Not quite - there are serial levels on TTL, and there is the RS-232 standard; the voltage levels are inverted, and different.
arduinomagbit:
2, can I use this usb-ttl's tx and rx pin to upload sketch to my standalone new avr mega8 chip?
Lovely picture! Yes, it will work fine but that module does not provide for the auto-reset function using a capacitor and 10k resistor (unless you are deft with a soldering iron) so you will have to learn to use the reset button on your board design to start the download - and of course you have to have the bootloader already installed on the mega8 and a suitably adapted "boards.txt" file.
arduinomagbit:
3, I have a UNO. Can I use the above USB-TTL to talk to my UNO? how?
The UNO already has a USB interface. What exactly is it you want to do?
Paul__B:
arduinomagbit:
1, is TTL same thing as serial?Not quite - there are serial levels on TTL, and there is the RS-232 standard; the voltage levels are inverted, and different.
arduinomagbit:
2, can I use this usb-ttl's tx and rx pin to upload sketch to my standalone new avr mega8 chip?Lovely picture! Yes, it will work fine but that module does not provide for the auto-reset function using a capacitor and 10k resistor (unless you are deft with a soldering iron) so you will have to learn to use the reset button on your board design to start the download - and of course you have to have the bootloader already installed on the mega8 and a suitably adapted "boards.txt" file.
arduinomagbit:
3, I have a UNO. Can I use the above USB-TTL to talk to my UNO? how?The UNO already has a USB interface. What exactly is it you want to do?
thanks a lot for the answer. I have already tried using an uno to talk to this USB-ttl. I uploaded a( Serial.print("test")) to my uno, and connect pin Tx in my uno to this USB-ttl adapter's Rx pin. It reads out fine, but I have another question. Why it's not Tx pin connect to Tx pin? it doesn't work with Tx connected to Tx, Rx to Rx.
also, I got one of those RF, radio frequency mini board. I use it on my uno to talk to my computer using this usb-ttl, but a lot of random code shows up. I think that is noise, right? how to avoid that?
(deleted)
arduinomagbit:
Why it's not Tx pin connect to Tx pin? it doesn't work with Tx connected to Tx, Rx to Rx.
Because when you connect two devices together which are "peers", what one transmits is received by the other - in each direction, so the connections must cross over.
arduinomagbit:
also, I got one of those RF, radio frequency mini board. I use it on my uno to talk to my computer using this usb-ttl, but a lot of random code shows up. I think that is noise, right? how to avoid that?
Radio - especially AM radio - is noisy. While your ears can find meaning amongst a modest degree of noise, digital communications systems need to be designed to manage it, and particularly to determine when something is being sent and when it is not. This is achieved by "packet" protocols where packets contain synchronising patterns and checksums as well as the data, and mechanisms acknowledge and/ or repeat packets that fail to be received correctly.
Paul__B:
arduinomagbit:
Why it's not Tx pin connect to Tx pin? it doesn't work with Tx connected to Tx, Rx to Rx.Because when you connect two devices together which are "peers", what one transmits is received by the other - in each direction, so the connections must cross over.
arduinomagbit:
also, I got one of those RF, radio frequency mini board. I use it on my uno to talk to my computer using this usb-ttl, but a lot of random code shows up. I think that is noise, right? how to avoid that?Radio - especially AM radio - is noisy. While your ears can find meaning amongst a modest degree of noise, digital communications systems need to be designed to manage it, and particularly to determine when something is being sent and when it is not. This is achieved by "packet" protocols where packets contain synchronising patterns and checksums as well as the data, and mechanisms acknowledge and/ or repeat packets that fail to be received correctly.
I see.
it's one of these, very cheap and useful.
Receiver module parameters
Product Model MX-05V
Operating voltage: DC5V
Quiescent current: 4mA
Receiving frequency: 433MHZ
Receiver sensitivity:-105DB
Size: 30 * 14 * 7mm
An extra antenna is needed, please use spiral 50? a quarter wavelength antenna
Technical parameters of the transmitter head
Product Model: MX-FS-03V
Launch distance :20-200 meters (different voltage, different results)
Operating voltage :3.5-12V
Dimensions: 19 * 19mm
Operating mode: AM
Transfer rate: 4KB/s
Transmitting power: 10mW
Transmitting frequency: 433M
Pinout from left to right: (DATA; VCC; GND)
I rather thought as much.
You illustrate a "superregen" receiver. They are a very simple design and very sensitive, but have a number of troublesome characteristics; they have a very wide bandwidth, often the whole of the frequency band in which they operate so they cannot distinguish data sent on different channels; they have a "capture" effect where when there is signal, they follow the signal very well but when there is no signal, they generate a tremendous amount of noise which cannot be "squelched" so that for data, they will be generating a continuous "nonsense" data stream as you describe and finally because they actually oscillate on the signal frequency, they interfere with any other receiver in close proximity. You may have noticed this effect when your car fails to respond to the remote control with any reasonable range (sometimes not at all) when in a parking lot beside other cars - because they are all using similar superregen receivers.
Paul__B:
I rather thought as much.You illustrate a "superregen" receiver. They are a very simple design and very sensitive, but have a number of troublesome characteristics; they have a very wide bandwidth, often the whole of the frequency band in which they operate so they cannot distinguish data sent on different channels; they have a "capture" effect where when there is signal, they follow the signal very well but when there is no signal, they generate a tremendous amount of noise which cannot be "squelched" so that for data, they will be generating a continuous "nonsense" data stream as you describe and finally because they actually oscillate on the signal frequency, they interfere with any other receiver in close proximity. You may have noticed this effect when your car fails to respond to the remote control with any reasonable range (sometimes not at all) when in a parking lot beside other cars - because they are all using similar superregen receivers.
thanks for the info. i will read more from wiki you pointed to
){kind=link}