<div dir="ltr"><div><div><div>Hmm. Reading through the docs, it seems that the internal oscillator is factory calibrated to within 10% (p304, table 29-9).<br>The datasheet also claims that for 8 bit UART the max error the receiver can tolerate is about 4.5% (p185, table 20-2).<br><a href="http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf">http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf</a><br><br></div>We did try comparing the internal clock against the on board watch crystal to try and catch anything wildly off, but I'll check any duds I come across with a frequency tester.<br><br></div>Regards,<br><br></div>Deniz<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 9:39 AM, Kevin Wood <span dir="ltr"><<a href="mailto:kevin@the-wood-family.com" target="_blank">kevin@the-wood-family.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Damon,<br>
<br>
If it's the RC oscillator then it will be far enough out to cause issues<br>
on long blocks of data in my experience.<br>
<br>
I'm not sure why this is a problem. As you say, it SHOULD be possible for<br>
the receiving UART to resync on every start bit, or, in fact, on every<br>
transition of the signal. The fact is that they don't appear to do so<br>
except on a start bit after the link has fallen idle, or, at least, the<br>
typical PC COM port or USB-to-Serial adaptor doesn't.<br>
<br>
Maybe the AVR's UART is more intelligent in this respect, and this is why<br>
we are not seeing corruption on firmware loads, since it's then the PC<br>
that is transmitting flat-out?<br>
<br>
Best Regards<br>
<br>
<br>
Kevin<br>
<span class=""><br>
> Hi,<br>
><br>
> The UART clocks being out relative to one another is in my view quite<br>
</span>> likely an issue since on our board’s side the clock is derived from the<br>
> AVR’s 8MHz internal RC clock.<br>
<span class="">><br>
> This does mainly seem to be an issue with solid blocks of characters (eg<br>
> ~16 or more bytes) being sent at once (to the AVR board), though I would<br>
> expect everything to resync on each start bit.<br>
><br>
</span>> I don’t believe any buffers are being overwritten since we are using the<br>
<span class="">> normal Arduino queued serial byte streams, with everything interrupt<br>
> driven, though that may be worth another look, thank you.<br>
><br>
> Puzzling!<br>
><br>
> Rgds<br>
><br>
> Damon<br>
><br>
><br>
><br>
>> On 28 Sep 2016, at 17:11, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
>><br>
>> Is this more than just UART being UART and the clocks of of each side<br>
>> being out?<br>
>><br>
>><br>
>><br>
>> Maybe try repeatedly sending 'U' on one of the problematic devices and<br>
>> measure the frequency, should be half the baud rate as U is 01010101<br>
>><br>
>><br>
>> IIRC you use a relatively slow baud rate (4800 IIRC) so you could be<br>
>> overwriting data in a buffer if you send data to fast?<br>
>><br>
>> Jeremy<br>
>><br>
>> On 28 Sep 2016 3:08 p.m., "Damon Hart-Davis" <<a href="mailto:damon@opentrv.uk">damon@opentrv.uk</a>> wrote:<br>
>> Hi,<br>
>><br>
>> We have a Wiki page here for our general amusement:<br>
>><br>
>> <a href="https://github.com/opentrv/OTWiki/wiki/Puzzling-Long-Term-Bugs" rel="noreferrer" target="_blank">https://github.com/opentrv/<wbr>OTWiki/wiki/Puzzling-Long-<wbr>Term-Bugs</a><br>
>><br>
</span>>> We’ve certainly been having some puzzlement while putting together a<br>
<span class="">>> small run of valves for a trial over the last few days. Could be<br>
</span>>> summarised as ‘dodgy serial’:<br>
<div class="HOEnZb"><div class="h5">>><br>
>> - Some REV7 and other V0p2 units seem to have problems with serial RX<br>
>> and TX, garbling some characters<br>
>> - Seems especially problematic for longer (16+?) blocks of<br>
>> characters such as setting a key<br>
>> - Have tried to ensure no sleeping or other fiddling with CPU clock<br>
>> during UART operation<br>
>> - Seems to apply to a few % of REV7, REV10 boards at least<br>
>> - It has been possible to load a large (30KB) app over serial with<br>
>> the bootloader.<br>
>><br>
>> Any ideas welcome!<br>
>><br>
>> Rgds<br>
>><br>
>> Damon<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> OpenTRV-dev mailing list<br>
>> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.<wbr>uk</a><br>
>> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/<wbr>listinfo/opentrv-dev</a><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenTRV-dev mailing list<br>
> <a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.<wbr>uk</a><br>
> <a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/<wbr>listinfo/opentrv-dev</a><br>
><br>
<br>
<br>
______________________________<wbr>_________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.<wbr>uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/<wbr>listinfo/opentrv-dev</a><br>
</div></div></blockquote></div><br></div>