Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Possible ASCII to UTF8 issues


Best Answer jschaud, 28 February 2013 - 04:42 PM

I found the answer. Something about the voltage levels doesn't let it understand that first bit. 

 

 

"I am certain that you cannot connect RS-232 levels directly to the serial pins on the Classic or the Plus."
 
 

http://forums.netdui...netduino-rs232/

Go to the full post


  • Please log in to reply
10 replies to this topic

#1 jschaud

jschaud

    New Member

  • Members
  • Pip
  • 8 posts

Posted 16 February 2013 - 02:15 AM

I am using a device that will pass ascii or hex to my Netduino and for now, I just want it to reply with the same string. My code is below. When I send abc, I get back "X,,". When I send 123, I get back "L&&". If I pass x01x02x03 I get back a "@". Could anyone give me some direction please.

 

 

 

 

 

 

 

 

using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;
using System.IO.Ports;
using System.Text;
using System.Collections;
 
 
namespace SerialNetduino
{
    public class Program
    {
        static System.IO.Ports.SerialPort port;
        static int count, readLength;
        static bool reading = false;
        static byte[] inTray;
 
        public static void Main()
        {
            port = new SerialPort("COM1", 9600, Parity.None, 8, StopBits.One);
            port.DataReceived += new SerialDataReceivedEventHandler(RecievedData);
            port.Open();
            Thread.Sleep(-1);
         
        }
        static void RecievedData(object sender, SerialDataReceivedEventArgs e)
        {
            int bytes = port.BytesToRead;
            byte[] data = new byte[bytes];
            port.Read(data, 0, bytes);
            port.Write(data, 0, bytes);
            if (!reading)
            {
                reading = true;
                count = 0;
                readLength = data[0];
                inTray = new byte[readLength + 1];
            }
 
            for (int i = 0; i < bytes; i++)
            {
                inTray[count] = data[i];
                count++;
            }


#2 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 17 February 2013 - 02:12 AM

Hi!

 

Your code looks ok to me.

 

What is your other endpoint, is it a PC, another Netduino or what?

 

Are you absolutely sure it is also configured for 9600|8|n|1?

 

What kind of link are you using between the two parties, FTDI cable, other?



#3 jschaud

jschaud

    New Member

  • Members
  • Pip
  • 8 posts

Posted 17 February 2013 - 11:23 PM

Hi Hanzibal, and thank you for the help. The other side is a home automation processor and is definitely on 9600. I have narrowed the issue down to something with how each side is treating byte values. If I send 'x00Poweron', the Netduino responds with 'Poweronx00', but if I do not lead with the x00, it gives back jibberish. 



#4 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 18 February 2013 - 12:09 AM

It sounds almost as if the automation processor does not send the start bit correctly. Maybe the automation processor uses some kind of unorthodox modulation? It really seems so to me. You say the automation processor is also set for 9600 baud, but what about the other parameters such as parity and stopbits - are you equally sure of those? If you have an oscillosxope or a logic analyzer, you could have a look and what actually comes out?

#5 jschaud

jschaud

    New Member

  • Members
  • Pip
  • 8 posts

Posted 18 February 2013 - 01:28 AM

Parity is definitely set to No, 8 data bits, 1 stop bit. The automation processor's operating system is built on top of the .net compact framework (Don't know if that matters at all). I don't have an oscilloscope or a logic analyzer, I'll keep working at it and see if I can work around it anyway. If you have any ideas, please let me know. Thank you again. 



#6 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 18 February 2013 - 08:59 AM

So, the automation processor runs on a PC - regarding the serial link:

 

1. What kind of serial device do you use on the PC in order to send commands to the Netduino?

2. Use a multimeter to verify that Rx and Tx lines are both at a high logic level when the line is idle

3. How long are the serial wires? If very long they could be subject of interference and/or attenuation

 

These are just few more suggestions of things you could check.



#7 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 18 February 2013 - 09:42 AM

For ASCII versus UTF-8, I never use UTF-8 on my netduino for strings, I always convert bytes to chars. Most hardware (text LCDs, GPS units, etc.) use ASCII anyways.

 

But the difference between both will only count for characters above byte 127 (see also: http://en.wikipedia.org/wiki/UTF-8)

So for normal characters a conversion isn't even required.

 

It could also be tha there's an MSB versus LSB issue. If that's the case, all bits are reversed. So 00001100 (0x0c) would become 00110000 (0x30).


"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#8 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 18 February 2013 - 10:08 AM

Diving into your values:

a = 0x61 = 01100001b = 0x62 = 01100010c = 0x63 = 01100011X = 0x58 = 01011000, = 0x2c = 11000010 abc = 01100001 01100010 01100011X,, = 01011000 11000010 110000101 = 0x31 = 001100012 = 0x32 = 001100103 = 0x33 = 00110011L = 0x4c = 01001100& = 0x26 = 00100110123 = 0011000 100110010 00110011L&& = 01001100 00100110 00100110    0x01 = 00000001    0x02 = 00000010    0x03 = 00000011    x00 = 00000000@ = 0x40 = 01000000x1x2x3 = 00000001 00000010 00000011  x0@x0 = 00000000 01000000 00000000  

It -looks- as if the first two bits at least are shifted. In all three situations, if I add two 0's at the first occurance, they're in sync for a few bits. Could be coincidence, but I would try to see if you have indeed your parity and stopbit settings the same on both sides.

abc = --011000 010110001001100011X,, = 01011000 1100001011000010123 = --001100 010011001000110011L&& = 01001100 0010011000100110x1x2x3 = --000000 010000001000000011  x0@x0 = 00000000 0100000000000000  

"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#9 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 18 February 2013 - 11:13 AM

If I send 'x00Poweron', the Netduino responds with 'Poweronx00', but if I do not lead with the x00, it gives back jibberish. 

This also points in the direction of that Stefan describes, bit sync errors over the serial line. The above plus the fact that data bytes are simply being looped back by the Netduino would suggest that it is indeed not a string encode/decode problem.



#10 jschaud

jschaud

    New Member

  • Members
  • Pip
  • 8 posts

Posted 18 February 2013 - 03:36 PM

Hanzibal, the automation processor is a standalone piece of hardware with serial ports and its own programming language. I can have it send out any command I would like via its debugging software. I will try to put my hands on a multi-meter this week and see if something is going on with its start voltage. The serial wires are 3 6 inch long breadboard wires going from the TX, RX, and ground of the automation processor into pins 0,1,and GND on the netduino. 

 

Stefan, If I am understanding you correctly, the line is not holding the rs232 signal voltage correctly before a transmission, which indicates the first two bits are enabling the transmission, but getting treated as the start bit, and then the rest of the transmission is going through correctly. 

 

I tested further this morning and the netduino only echoes the characters back correctly if I send x00 first. Since I am a complete beginner with the hardware side of rs232, I am guessing here. The x00 byte is acting as the start bit and everything else is working fine after that. 

 

I have checked again and the processor definitely thinks it is at 8|n|1. I changed the baud on both sides to 19.2 to see if I got any different behavior. Nothing changed with the different baud rate. 

 

Thank you again for your ideas. I really appreciate your input. 



#11 jschaud

jschaud

    New Member

  • Members
  • Pip
  • 8 posts

Posted 28 February 2013 - 04:42 PM   Best Answer

I found the answer. Something about the voltage levels doesn't let it understand that first bit. 

 

 

"I am certain that you cannot connect RS-232 levels directly to the serial pins on the Classic or the Plus."
 
 

http://forums.netdui...netduino-rs232/






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.