Hello,
I am in need of using the serial pin D0 to read data from my smart-electricity meter as the AltSoftSerial or SoftwareSerial keep producing some error characters amongst the data being sent. Thus this makes it unreliable.
I had written a script using the Bridge library and AltSoftSerial library but that needs changing. I think however, that pin D0 is already used by the Bridge. Is this correct? Would there be a work-around to not use the SoftwareSerial or AltSoftSerial but still use the bridge and pin D0 for receiving my serial data?
Thanks in advance!
Yes, pins D0 and D1 are used by the Bridge communications to the Linux processor. You have two choices:
- Don't use pins D0 and D1 for hardware connections, and use those pins to talk to the Linux processor
- Use those pins for hardware connections, and don't use the Linux processor (but you might as well just use a Leonardo in that case, and save yourself a lot of money.
You simply cannot use those pins for Linux communication, AND for talking to another device at the same time.
I have had good luck with SofwareSerial, so I'm not sure what is causing problems for you. You say it's unreliable because you get some error characters - well, ANY serial connection, including using the D0 and D1 pins can be unreliable. If you can't tolerate an occasional bad character, then regardless of your connection method (hardware or software) you should probably come up with a communications protocol that has error detection ability (such packets with a checksum or CRC) and an ability to retransmit bad packets. It sounds like a lot of work, but it is a very typical thing to do when you are using serial communications and data reliability is important.
Hi ShapeShifter (and others),
I placed a shield on top of my Yun to connect the smartmeter to the Yun. It uses 115200 baud and I think it does go wrong at that stage with using the SoftwareSerial. If I use a jumper wire to pin D0 (from my origional soldering connection) there are 0 errors in each messaged. This tells me two things. 1) my soldering is correct, 2) the hardware serial works best. I have no way of setting a different baud rate on the device that sends the messages.
Unfortunately I bought a Yun already and it looks like I am not be able to use it after all. I think I need to re-write the sketch for my uno with ethernetshield and just have to send everything to my Yun (but I could just use mu nas instead).
Another option would be a serial to usb thing but the usb can only be used by the Linux side if I am correct. Thanks for the answer.
Here are some printouts from the serialMonitor. If used the monitor on 9600 baud as well as 115200 baud and the output is much the same.
D0 pin:
/XMX5LGBBFFB231284080
1-3:0.2.8(42)
0-0:1.0.0(160322153727W)
0-0:96.1.1(4530303031303031363634363035363135)
1-0:1.8.1(000741.439*kWh)
1,0:2.8.1(000000.000*kWh)
1-0:1.8.2(000698.469*kWh)
1-0:2.8.2(000000.000*kWh)
0!0:96.14.0(0002)
1-0:1.7.0(00.038*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00009)
0-0:96.7.9(00003)
1-0:99.97.0(3)(0-0:96.7.19)(1 0907003315S)(0000013740*s)(150805093629S)(0000003953*s)(150602103328S)(0000000291*s)
1-0:32.32.0(00001)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:31.7.0(000*A)
1-0:51.7.0(000*A)
1-0:71.7.0(000*A)
1-0:21.7.0(00.025*kW)
1-0:41.7.0(00.005*kW)
1-0:61.7.0(00.006*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000"kW)
1-0:62.7.0(00.000*kW)
0-2:24.1.0(003)
0-2:96.1.0(4730303032333430323037393036323135)
0-2:24.2.1(160322150000W)(00607.500*m3)
!62ED
altSoftserial:
/XMX5LGBBFFB231284080
1-3:0.2.8(42)
0-0:1.0.0(060331135046S)
0-0:96.1.1(4530303035303030363634363035363135)
1-0:1.8.1(000759.012*kWh)
1-0:2.8�1(000000.000*kwh)
1-0:1.8.2(000720.244*kPh)
1-0:2.8.2(0����r���RZ�h)
0-0:96.14.0�0002)
1-0:1.7.0(00.174*kW)
0-0:2.7.0(00.000*kW)
0-0:96.7.21(00009)
0-0:96.7.9(00003)
1-0:99.97.0(3)(0-0:96.7.19)(150907003314S)(0000013 40*s)(150805093629S�(0000003953:s)(150602103328S)(0000000295*s)
1-0:32.32.0(00001)
1-0:52.32.0(00000)
1-0:72.32.0(00000)
1-0:32.36.0(00000)
?-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.1()
0-0:96.13.0()
1-0:30.7.0(001*A)
1-0:51.7.0�000*A)
1-0:71.7.0�000*A)
1-0:21.7.0�00.109*kW)
1-0:41.7.0(00.004*kW)
1-0:61�7.0800.059*{W)
1-0:22.7.0(00.000*kW)
1-0:42.7.0 00.000*kW)
1-0:62.7.0�00.000*kW)
0-2:24.1.0(003)
0-2:96.1.0(4030003032333430323037390036323135)
0-2:24�2.1(160331130000S)(00621.804*m3)
!57E1
softwareSerial:
/XMX6LGBaFFB2313840 0
1-3:0.2. ,42)
0-0:1.0 0(17033113MS�ӫ�H�0-0:97.1 1(45303038�M&����������������������Jj
1-0:1.8 L �����r���RZ]��j
1-0:2.8 1(000000.0 0*kWh)
1.0:1.8 2(000720.2M��� +j
1-0:3.8�2(000000.0�0*kWh)
0-0:96.1 .0(0002)
1-0:1.� B��r���RZ]�j
1-0:2.� B��r���RZ]�j
0-0:96.�I�B�����Jj
0-0:96.�)B�����Jj 1-0:99/9� B�JB�j��ʲr�r��J�(1509070 331M�J
���������R���(1508050N&��N�J ������ʪ�R��(1506021�3338S)(000 000395*s)
1-0;32.&& B�����J5
1-0:52 && B�����Ju
1-0:72.&& B�����Ju
1-0:32 36.0(00000)C�1-0;52.&� B�����J5
1-0:73�36.0(00000JH�0-0:96.1&)BKj
0-0:96/1& BJj
1-0:31.� B���R
�j
1-0:51.� B���R
�j
1.0:71.� B���R
�j
1-0:31.� B��r���R�]�j
1-0:41.� B��r���RZW)
1-0:61 7.0(00.050*�U�H�1-0:22.� B��r���R[]�j
1-0;42 7.0(00.000*�U�H�1-0:62 � B��r���R[]�j
0-2:24.L B���Jj
0-2:96/1 0(473030&���������������ʚ���������Jj
0-2:24 2.0(160331L&����� ����rº�Rj�Jj !E178
They should all look more or less the same but you can see lots of error characters comming through using the altSoftserial or softwareSerial
arjan_hes:
If used the monitor on 9600 baud as well as 115200 baud and the output is much the same.
That is to be expected. If you are using a board like the Uno, which uses a separate chip to talk to the processor using the D0 and D1 lines, getting the baud rate correct is very important. It isn't used for the USB communications between your computer and the USB chip, but it used to set up the serial output of the USB chip, the side that talks to the processor - that speed MUST match the speed set in the Serial setup call.
But with the Yun, there is no separate USB chip - the USB interface is in the processor itself. That means that the baud rate is pretty much meaningless and ignored. You still have to specify something, due to legacy reasons, but it can be anything and doesn't matter whether it matches what's in the serial monitor. The USB side of the connection always runs at high speed, and there is no actual asynchronous serial data stream that needs to have a speed specified.
They should all look more or less the same but you can see lots of error characters comming through using the altSoftserial or softwareSerial
I notice that even the D0 version has at least one transmission error: the fifth sample line starts with "1,0" where it should clearly be "1-0". If a punctuation/delimiter character can get corrupted, a critical data value can be corrupted as well.
What are your connections like? Are your serial wires long? Are they routed near or parallel to the AC power wires? I wonder if you are getting some electrical noise on the wire? Perhaps the hardware serial port has better noise immunity than the software serial port? Better, perhaps, but not completely better, as the hardware port is apparently susceptible to corrupted characters as well.
Maybe your true solution is to use short shielded serial wires? If using shielded cable, ground the shield, but only on one end, leave the other end of the shield disconnected. You don't want it to be able to conduct any current and create a ground loop.