1
\$\begingroup\$

I plan to run the atmega328p without external oscillator like in this tutorial:

http://www.instructables.com/id/Atmega-Standalone-Running-without-crystal-oscillat/?ALLSTEPS

Some guy here saying:

"The internal oscillator does lead to inaccuracies but I2C is one of those protocols that does not require a synchronized clock with the device it's interfacing with, so no I2C will not be adversely effected by the internal oscillator. The protocol that does require a higher level of accuracy is UART or 'Serial'. Without getting into too much details the faster your baudrate of your UART the more likely there is to be errors. So if you are going to use a UART with the internal oscillator just try out a baudrate like 115200 and see if there is garbage outputting to the Serial Monitor if so reduce the baudrate to 57600. I've personally seen garbage come out on 115200 but that was not consistent. It's probably because the oscillator is temperature dependant."

Could using the internal oscillator cause a problem with wireless communication with 433MHZ RF transmitter using the VirtualWire library?

Thanks

\$\endgroup\$
  • \$\begingroup\$ According to the VirtualWire official documentation open.com.au/mikem/arduino/VirtualWire.pdf the datarate may vary a lot so it looks to me as if the protocol that it is using for sending the information is very flexible with regard to the timing. That would mean the internal oscillator is good enough for your purposes. But the proof is in the pudding, so just try it and see ! \$\endgroup\$ – Bimpelrekkie Feb 17 '16 at 14:51
  • \$\begingroup\$ You should look at the documentation for each tranceiver that VirtualWire supports. If the method of communication is I2C, you're fine, and if the method is UART, you're not (or may not be) \$\endgroup\$ – Scott Seidman Feb 17 '16 at 15:03
  • \$\begingroup\$ "probably because the oscillator is temperature dependant" Yes it is, widely-so. even I2C timing is important, if the clock jitter is so bad that it misses an inter-bit timing then the I2C command would be lost or rejected due to time-out. \$\endgroup\$ – KyranF Feb 17 '16 at 16:28
1
\$\begingroup\$

When using the simple RF transmitter receiver modules that don't include any protocols of their own like Virtual Wire is designed to work with jitter on the received data can be a problem. RF Monolithics have a good application not called Unique considerations for data radio UARTs that goes into some detail on this and it shows how to use a PLL (phase locked loop) to overcome the problem. The received data is over-sampled and when the received data edge is detected it feeds back into the loop so that the jitter is compensated for.

Virtual Wire uses a similar technique and samples the data eight times per second so an initial clock error of 12.5% would only be causing the data to be shifted by one bit which the loop would quickly compensate for while it was receiving the preamble. Then the RC oscillator will mainly drift with voltage and temperature changes which will be negligible over the transmission period so I don't think you'll have any problems at all.

For a normal UART that doesn't have that PLL scheme I normally like to keep errors on both ends at under 2% otherwise you can run into problems which is what the above is talking about. That's why a normal UART doesn't work so well with those sorts of RF modules that can have quite a bit of jitter and that's one of the things Virtual Wire is designed to get around.

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

It depends on the application, wireless communication is not designed for timing critical applications in this case accuracy is not important. But, if you're looking for real time applications you need to add synchronization methods like TDMA.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.