[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rxtx
Subject:    Re: [Rxtx] Detecting broken connections?
From:       Juey Chong Ong <ong () neomancer ! net>
Date:       2009-05-01 0:04:56
Message-ID: 17C3399F-1B67-4E55-A824-67D8D86FCA7D () neomancer ! net
[Download RAW message or body]

Hi Gili:

Sounds like your customer is rather demanding. :-)  Is this a consumer- 
oriented product? I tend to associate RS-232 connections with point-to- 
point communications and if they want to set up some sort of daisy  
chaining, they should consider whether it's a good idea from a  
usability point of view. Particularly if there's some sort of master- 
slave or device addressing involved, is this negotiation part of the  
communications protocol (which makes it more complex) or is it based  
on flipping some DIP switches (which makes it harder on the user ---  
I'm just recalling how many times I forgot to flip the DIP switches on  
a IDE or SCSI device)?

Regarding the handling of corrupt frames: this might sound simplistic,  
but if you receive a corrupt frame, just throw it out and request for  
another frame. If it's streaming packets to you, there should be a  
sort of packet header following the SoP with various pieces of  
information like the packet type, length, etc. I think that should be  
sufficient information to differentiate a real SoP versus a corrupt  
sequence that looks like a SoP. This approach has been sufficient for  
the kinds of devices I used to write software for --- Lexicon  
receivers and various 3D input devices where occasional corrupted data  
wasn't particularly critical. I would assume that if reliability and  
accuracy were more important, or needs to be guaranteed, then you  
might need to design a protocol with those requirements in mind. Then,  
perhaps PPP might be appropriate.

--jc



On Apr 27, 2009, at 12:38 PM, cowwoc wrote:

> Hi Juey,
>
> 	I took a look at Lexicon. You're right! It's quite a bit simpler  
> and will probably do the job.
>
> 	I'm getting in touch with the customer today to clarify the  
> requirements. I heard rumors of various feature requests that freak  
> me out ;) For example, they might want to chain one device behind  
> another and I would need to be able to manage both off a single  
> connection. The other feature we discussed before was auto-baud  
> detection. I'll know more later on today...
>
> 	One thing that worried me about the Lexicon protocol is how corrupt  
> frames or disconnection are handled. The protocol says peers should  
> wait for the Start Of Packet byte. But how do you differentiate  
> between that byte in the middle of a corrupt frame versus at the  
> beginning of a frame? I was thinking that maybe the peer should wait  
> for "silence" for X milliseconds before the SoP byte. What do you  
> think?
>
> Thanks,
> Gili
>
> Juey Chong Ong wrote:
>> You might want to take a look at one of the Lexicon protocols as a  
>> starting point in your protocol design. e.g.:
>>    http://www.lexicon.com/products/download-details.asp?ID=1&FileID=119
>> You can do a search on Lexicon's web site under Support ->  
>> Downloads. In the Advanced Search section, select "Serial Protocol  
>> Definitions" and click on Search to bring up the entire list.
>> It was relatively easy for me to get my Mac talking to the MC-12  
>> with a Rxtx-based project and a Keyspan USB-to-RS232 dongle. My  
>> guess (actually, my personal preference) is developers would want  
>> something that's easy to work with.
>> I don't know what type of A/V equipment you're developing, but  
>> imho, PPP sounds too heavyweight. I'm not sure what type of  
>> equipment or environment you're targeting, but my impression is  
>> that typically a reliable hardwired connection to A/V equipment is  
>> assumed.
>> --jc
>> On Apr 23, 2009, at 11:43 PM, cowwoc wrote:
>>>
>>>    GUI software used to administer A/V equipment connected via  
>>> serial
>>> port. I tried designing my own protocol but I keep on running into
>>> unexpected hang conditions because I didn't foresee different  
>>> kinds of
>>> disconnects or errors.
>>>
>>>    My main goal is to achieve stable communication. Auto-baud and  
>>> robust
>>> disconnect handling are secondary. If I hand the hardware guys  
>>> existing
>>> C/C++ code I think they'd be happy to use whatever I give them. The
>>> question is whether PPP is the right way to go or whether there is a
>>> lighter solution that would get this done. As far as I know,  
>>> security is
>>> a non-issue. I just want a reliable data-layer to build an  
>>> application
>>> on top of.
>>>
>>> Gili
>>>
>>> Jim Redman wrote:
>>>>>   Do you think this protocol is too heavy for the kind of  
>>>>> product I
>>>>> am building? It handles all the connection management headache  
>>>>> for me
>>>>> as well as being an industry standard.
>>>>
>>>> What are you building?
>>>>
>>>> Jim
>>>>
>>>>>
>>>>>   I'm wondering whether there are some good (free?) Java and C/C++
>>>>> implementations of PPP. If so it would probably make this a viable
>>>>> option.
>>>>>
>>>>> Gili
>>>>>
>>>>> cowwoc wrote:
>>>>>> Hi John and Jim,
>>>>>>
>>>>>>   I really appreciate your descriptions. They've given me some
>>>>>> ideas on where to go from here.
>>>>>>
>>>>>>   In response to Jim, the reason I am looking at baud detection  
>>>>>> is
>>>>>> that my software is supposed to act as the front-end of an entire
>>>>>> product line of hardware. My customer likes using long wires so  
>>>>>> I can
>>>>>> foresee the need to use different baud rates for different  
>>>>>> devices.
>>>>>> That being said, it's still a guess (I should actually ask the
>>>>>> customer!). I worry about leaving this out of the protocol and  
>>>>>> then
>>>>>> having to add it in the future. I don't see an easy way of adding
>>>>>> this after-the-fact while maintaining backwards compatibility  
>>>>>> with
>>>>>> devices that have already been sold.
>>>>>>
>>>>>>   John, on the topic of multi-thread hangs, isn't that a RXTX  
>>>>>> bug?
>>>>>> Shouldn't we be able to use a com port from different threads  
>>>>>> so long
>>>>>> as they don't interact with it at the same time? Can you  
>>>>>> reproduce
>>>>>> this behavior with the latest version of RXTX?
>>>>>>
>>>>>> Thanks,
>>>>>> Gili
>>>>>>
>>>>>> John Coffey wrote:
>>>>>>> Anyway, unless I am mistaken - the difficult thing I had to  
>>>>>>> handle
>>>>>>> was to ensure that I closed and re-opened the comm port from  
>>>>>>> within
>>>>>>> the same thread that I originally opened it or I would get  
>>>>>>> lockups.
>>>>>>>
>>>>>>> John Coffey
>>>>>>> Gables Engineering
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>> _______________________________________________
>>> Rxtx mailing list
>>> Rxtx@qbang.org
>>> http://mailman.qbang.org/mailman/listinfo/rxtx


_______________________________________________
Rxtx mailing list
Rxtx@qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]