10-23-2008 10:05 PM - edited 10-23-2008 10:07 PM
When I obtained my bitstream from the modem or radio, there is no garantee that I will always obtain the first bit of the unicode. For instance:
H=01001000
e=01100101
l=01101100
l=01101100
o=01101111
so instead of getting:
0100100001100101011011000110110001101111
I might get something like this:
100001100101011011000110110001101111
or this
100100001100101011011000110110001101111
or this
00001100101011011000110110001101111
and so on....
as the result of not obtaining the perfect alignment I can't convert the recovered bit stream to unicode characters. Is there anyway to work around this so I can recover any arbitrary bit stream received? If I know what is being transmitted ahead of time, I can work around this but unfortunately, I don't.... I've searched everywhere and still no avail, I'm sure there is a solution but I must be missing somethin. thanks
10-23-2008 11:00 PM
First, the example you are showing is not "Unicode". It is ASCII.
How are you receiving these bits? What LabVIEW functions are you using to get the bitstream from the radio or modem?
Normal serial communication protocols use start bits and stop bits to define where each byte starts and stops. Otherwise you'd have the mess you are describing where you dont' know where one byte begins or ends.
You can't do anything to recover any missing data, but we would need more information on exactly what you are doing and how you are getting this data from this "radio" or modem"?
10-24-2008 09:30 AM
If you get a finite dataset and know that it always ENDS at a character boundary, you could work backwards.
If it is a continuous stream, then the sender MUST put some synchronizing information into the stream. As Ravens Fan pointed out this is often in the form of start and stop bits, but it can also be a synchronizing character which never occurs in the data set. If all possible characters can occur in the data, then a higher level protocol must be established to frame the data. For example a group of characters which will never occur can be used or and "escape" mechanism which reserves special characters but allows them to be sent by duplicating them.
Lynn
10-24-2008 03:35 PM
10-24-2008 03:41 PM
Lynn,
You're right I do have sync preamble to go with but the modem/radio job was simply FIFO ...that being said, the first bit it receives is the first bits it sends off ....it puts into a frame into the data sectio of the frame, the header of the frame is obviously the sync header. The DTE that keys these modem/radio that I'm testing is a TTC Fireberd. If I'm sending an all 1 or 10 alternation, it's pretty easy to detect but it becomes difficult when I send ASCII codes such as FOX, or any programmable string.
10-24-2008 03:44 PM
I think I'll be fine with this one, I just gotta brute force the first couple of bytes with a bit increment until I can detect a valid character then I'll take it off from there.