LCDproc development and user support list

Text archives Help


[Lcdproc] #twatch network LCD backpack


Chronological Thread 
  • From: david.glaude at gmail.com (David Glaude)
  • Subject: [Lcdproc] #twatch network LCD backpack
  • Date: Sun, 3 Jan 2010 02:30:54 +0100

Hello,

For those that remind me (David Glaude)... no I am not back yet into LCDproc
developpement... mostly because I don't have a linux computer handy for that
and because I should clear with my day job any issue about my right to
release software I develop during the night under GPL.

I contact you because I made a nice discovery, fastly followed by an
aquisition (the hardware is now running next to me). And I would love (I am
not alone) to use that under LCDproc control.

It is a networked LCD with enough hardware to hold a twitter "client" and
emulate a subset of Matrix Orbital protocol when those byte are send over a
TCP connection on port 1337.
http://dangerousprototypes.com/twatch-manual/
http://dangerousprototypes.com/category/twatch/

I don't think this hardware can run a full LCDproc server... so it still
need an LCDproc server to drive it.

What is missing is a new driver (a simplified MatrixOrbital driver wich open
the TCP connection).
Maybe it is possible to write a program that fake and /dev/ttyS device and
make the TCP connection and bridge every byte. Then run the MO driver to
send to this "device" (assuming enough of MO protocol is emulated).

Is there any driver currently in LCDproc CVS that does a TCP connection?

I remember that years ago, I had the plan to separate in driver what is
relative to the "protocol" and what is relative to the "communication
channel".
Somehow, each and every driver does rewrite (copy and paste) the code to
open a serial interface and set the speed (or else).
Here (maybe for the first time) we have a known protocol (MO) with an unknow
communication channel (Open a TCP connection).
Did anybody work on this idea?

If #twatch firmware was to be modified or rewritten from scratch, what would
you have done differently?
My idea:
* Drop the twitter client
* Make it more LCDproc specific (trying to match LCDproc driver API)

At least, there is a potential for LCDproc specific firmware or feature.

Was MO protocol decision the best one? (I was more impress by CF633 packet
protocol that could be done over UDP)?

Well, I wanted to let you know about this device, let you know that I might
start working on it, gather information from the list about the option.

Thanks in advance.

David Glaude

PS: This is what someone posted on
http://dangerousprototypes.com/2009/09/17/prototype-network-lcd-backpack-with-lcd-smartie/
**

"LCD Smartie and LCDproc are open source, so anyone can add a few
enhancements for ethernet LCD backpacks. It would be great if they could
control an LCD backpack directly over TCP, without a bridge."
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.omnipotent.net/pipermail/lcdproc/attachments/20100103/eff541d7/attachment.html>




Archive powered by MHonArc 2.6.18.

Top of page