LCDproc development and user support list

Text archives Help

[Lcdproc] LCDproc 0.5.2 released

Chronological Thread 
  • From: ethan.dicks AT (Ethan Dicks)
  • Subject: [Lcdproc] LCDproc 0.5.2 released
  • Date: Fri Apr 27 17:51:01 2007

On 4/27/07, Peter Marschall
<peter AT>
> Hi,
> On Friday, 27. April 2007 15:21, Ethan Dicks wrote:
> > As for the rest, I can confirm that the lcd2usb driver works for me
> > with one of the recent CVS nightlies with a 20x4 VFD and a 4x40 LCD
> So you got a 2-controller display working on the lcd2usb driver ?
> Cool !

Yep. Since the Densitron 4790 has a 16x1 connector, with E2 on pin
15, and optional Vee-out on pin 16 (if your display generates Vee
locally), I hacked my lcd2usb to put E2 on pin 15 and hacked my
display to completely isolate pin 16 only so I could "backpack" the
lcd2usb. I could have accomplished the same effect with no hardware
changes with a suitable cable.

> I wrote the 2-driver support without having such a display, and hoped
> for the best.

It worked the first time.

> Thanks for the feedback: now I can update the docs accordingly.

You bet.

> BTW: Do you need to use vspan=2,2 ?

Yes. Here's the relevant section of my LCDd.conf
# Specifies the size of the LCD.
# In case of multiple combined displays, this should be the total size.

# For multiple combined displays: how many lines does each display have.
# Vspan=2,2 means both displays have 2 lines.

> > I had been working on some enhancements and bugfixes...
> > for
> Cool.
> I have read your previous post about, but did not get 'round to
> write my ideas about the patches.
> It would be great if your patches to were independent of the
> patches to Geo::METAR.

They are. The updates to are to support a wider display
(optionally writing out temps in both C and F if there's enough
width), and to optionally support in-charROM degree symbols if your
display supports them (the Noritake VFD I have on my lcd2usb and on my
Matrix Orbital VKD204 have a single char "degrees F" and "degrees C"
glyph). At the moment, there's a section at the top of
where you assign the LCDd server port address, etc, to which I've
added the ability to tell the client if you want "ASCII" (just 'C' and
'F'), a European char ROM degree symbol plus 'C' and 'F', a Japanese
char ROM degree symbol plus 'C' and 'F', or the VFD single char
'degrees C' and 'degrees F' glyph.

It looks like this at the moment...

# ASCII temp scale tokens, or VFD special char temp scale tokens?
# Can be "ASCII", "eLCD" (European charset), "jLCD" (Japanese charset),
# or "VFD"
my $degreetype = "ASCII";

# What to use to mark temps in degrees F and degrees C
# \337 is the degree symbol on many LCDs
# \033 and \032 are a single-char 'degrees F' and 'degrees C' glyph
# on some models of VFD, notably the Noritake CU20045SCPB-W2J that
# ships with Japanese-charset Matrix Oribital VFD modules. These
# chars might not be present in some newer rev VFDs with a European
# charset in the VFD module.
# If your display has some particular char you prefer, add it to the
# two hashes below and change $degreetype to select it.
my %degreesF = ( 'ASCII' => "F", 'eLCD' => "\260F", 'jLCD' => "\337F",
'VFD' => "\033" );
my %degreesC = ( 'ASCII' => "C", 'eLCD' => "\260C", 'jLCD' => "\337C",
'VFD' => "\032" );

my $degreeF = $degreesF{$degreetype};
my $degreeC = $degreesC{$degreetype};

(then in the code. replace hardcoded "F" and "C" strings with $degreeF
and $degreeC).

> This way we can update and provide the patches to Geo::METAR
> in contrib/ for those users that want/need to upgrade their Geo::METAR.

Sure. The changes I have made are complementary but independent of
each other. You can update one but not the other, but, obviously,
it's best to do both.

> If they (partially) depend on the Geo::METAR patches, we can add
> the independent part to directcly and add the other
> parts as a patch in contrib/ next to the Geo::Metar patches

The patches to Geo::METAR are to eliminate Perl warnings when you ask
Geo::METAR to process non-US METAR strings with visibility tokens in
an "unexpected" format, or station IDs that don't begin with a "K", or
when temps are represented without a dew-point component. If you are
only feeding US observations into Geo::METAR, you don't "need" to
update Geo::METAR, but if you want to work with data from out of the
US, things aren't so pretty.

> Of course another option is to contact the Geo::METAR owner on CPAN
> urging him to up bring out an updated version of the package with your
> patches or to upload a noew version yourself [don't know if this is possible
> in CPAN] ;-)))

I wrote Jeremy Zawodny about Geo::METAR a little while back. Koos,
the author of the unofficial Geo::METAR v1.15 patch I posted a link to
the other day, wrote Jeremy quite some time ago. He has yet to
respond to either of us, and neither Koos nor I know how to get CPAN
to accept module upgrades or reassign apparently abandoned modules to
get any Geo::METAR patches into the CPAN repository.

I have asked Koos if we can distribute his patch, or a descendent of
his patch, with - that way, if some user wants
to patch his local copy of Geo::METAR, they have it right there in the
directory. He asked for a few days to look things over before giving
an answer.


Archive powered by MHonArc 2.6.18.

Top of page