UDP Driver

[Canavan, P. S \(UK - London\) <pca...@de...>]

Has anyone any experience with the UDP driver and\or writing raw code =
configs?=20

I'm trying to write an app to simulate a "remote" remote control over =
ethernet, and am successfully sending UDP packets to LIRC. I've =
determined that they are failing to match any button definitions in my =
config file (with receive_decode), and am trying to determine what the =
config file *should* have in it. I believe that:

1) UDP accepts pulse\space packets in byte pairs, with the duration in =
1/16K of a second periods.
2) LIRC works with pulse\space packets in microsecond periods.
3) RAW codes are configured with an odd number of duration declarations =
(even if you use CONST_LENGTH).=20

Given I know exactly what's being sent, how do I tell LIRC what to =
expect? irrecord doesn't seem to notice any inbound events, but I've not =
had chance to trace it through and work out why. I've spotted a couple =
of comparable questions in the archives, but they didn't seem to have =
been answered. Raw code examples on the net seem to all use a single =
number (the actual code?) rather than a set of duration values.


PS:  If there's a better route than RAW codes then that's fine, too :-)
PPS: I'm adding function comments to my local codebase as I work through =
it, to keep track of what goes on in each routine. Is there any interest =
in someone QA'ing and then merging these if I produce a diff file?


Philip.
=20
IMPORTANT NOTICE
If you have received this e-mail in error or wish to read our e-mail =
disclaimer statement and monitoring policy, please refer to the =
statement below or contact the sender.
This communication is from Deloitte MCS Limited whose registered office =
is at Hill House, 1 Little New Street, London EC4A 3TR, United Kingdom.  =
Registered in England No 3311052. =20
This communication and any attachments contain information which is =
confidential and may also be privileged.  It is for the exclusive use of =
the intended recipient(s).  If you are not the intended recipient(s) =
please note that any form of disclosure, distribution, copying or use of =
this communication or the information in it or in any attachments is =
strictly prohibited and may be unlawful.  If you have received this =
communication in error, please return it with the title "received in =
error" to IT....@de... then delete the email and =
destroy any copies of it.
E-mail communications cannot be guaranteed to be secure or error free, =
as information could be intercepted, corrupted, amended, lost, =
destroyed, arrive late or incomplete, or contain viruses.  We do not =
accept liability for any such matters or their consequences.  Anyone who =
communicates with us by e-mail is taken to accept the risks in doing so.
When addressed to our clients, any opinions or advice contained in this =
e-mail and any attachments are subject to the terms and conditions =
expressed in the governing Deloitte MCS Limited client engagement =
letter.
Opinions, conclusions and other information in this e-mail and any =
attachments which do not relate to the official business of the firm are =
neither given nor endorsed by it.