¿ªÔÆÌåÓý

Date

Locked Re: SoundPro Map Engine Start - And UK Sounds

 

Thanks..
Has anyone posted any UK VSD files? For any locos? Is their a library??


Locked Re: VSDecoder: Problems with xml and sound #vsdecoder #rpi #ubuntu

 

Thanks.. I'd not found that page! Need to find some more time to have a play.

Cheers,
Scott.


Locked Re: Decoder Pro problems

Peter Ross
 

Thanks Ken but that reply just makes it worse. What I'm asking for is phrases that have a clear meaning, never mind their history. At the coal face we just need to know which option to take and what will happen when we do.
Like I said, "Read decoder", "Write changes to file", that sort of thing. I realise this would take a while to work through so in the meantime could we have a little conversion table perhaps?
Looking at the TCS tab for a decoder I'm working with I see the following phrases:
"Read changes on sheet", "Write changes on sheet", "Read full sheet", "Write full sheet"
"Read changes on all sheets", "Write changes on all sheets", "Read all sheets, "Write all sheets".
I thought I might be able to suggest different words but I soon bogged down because I just don't know what each phrase is intended to say. If "Read changes on sheet" actually means (?), "Read decoder changes", then what does "Read changes on all sheets" mean? From a user perspective a decoder does not exist in parts. We can read the decoder and with a bit of help we can read just the changes, but I don't get the distinction implied by the word "all". I've read that in DecoderPro "all" can take a long time. Also do "full" and "all" have the same or different meanings?
Sorry, but I just find this area quite opaque and therefore confusing.
Regards
Peter


Locked Re: SoundPro

 

Marc,

The question was how to launch SoundPro. You showed the way and it works. I would prefere to copy the SoundPro icon and paste the icon as a Desktop link (as you said in your second post).

In most cases however I access SoundPro with PanelPro >> Tools >> Tables
Audio. This helps me to see wheather the audio objects like buffer,
source or listener are ready for an application to play the sounds.

One player application is Virtual Sound Decoder (VSD), and I think (and may be wrong), people sometimes say SoundPro but are thinking of VSD.

VSD add locomotive sounds to a layout without the need of sound decoders. I'm using Audacity to prepare the sounds (WAV files) for VSD. A SPJ file contains a WAV file for locomotive sound. And Audacity obviously can import a SPJ file.

Just my thoughts on this.

Klaus


Am 03.01.2019 um 23:44 schrieb Marc:
" How do I access soundPro from JMRI"
WIn10:
1 - you open that WINDOW, lower left side
2 - Scroll down to JMRI
3 - Do a right click on SOUNDPRO? and do a Pin to start? or Pin to Taskbar (which is deeper).
Hope I understood your request.
What SPJ files are you talking about.? I downloaded Audacity thinking we were talking DIGITRAX SPJ files.? Clearly not the case.
Marc


Locked Re: MQTT Connection in JMRI

 

Thanks Chris, clearly we can exceed 64 bytes with ESP8266?devices?- your example has 207. Perhaps when the 64 character limit was mentioned, it was with some other device in mind.

I have looked further into the possible inconsistencies between Heads and Masts I mentioned yesterday.?
Flashing is no issue. the xml files for appearances use "flashred" but when a head is included in a mast, the head shows this as "Flashing Red"
Regarding Lunar, it depends on which options you choose in creating the head. Virtual Heads do not have Lunar as an option. If you include that in a Signal Head Controlled Mast, the head appearance becomes null so could be considered as a bug or limitation in the current use of Virtual Heads with Signal Head Controlled Masts.?This digresses a bit from the objective of this discussion but worth mentioning as a reminder when coding for MQTT signal heads that Lunar and Flashing Lunar should be permitted. If we could add flashing frequency to it, I could say the Lunar ticks are on the Mast (apologies to Pink Floyd and everyone reading this, there's someone in my head but it's not me.)

Getting back to business, the objectives here are to define precisely what content and syntax will be created by JMRI for MQTT messages from the information held in JMRI and for sensors, to define the content and syntax of MQTT messages created by a remote sensor when it announces its state so that JMRI can interpret that message to identify which JMRI sensor it is and update its status in JMRI. Then Bob can do the coding.

The current format already in JMRI for turnouts only is /trains/track/turnout/{number} {state}? ?e.g.? ?/trains/track/turnout/27 THROWN? ?
The hardware address is MT{number)? e.g. MT27? where M is the prefix assigned to the MQTT connection and T for Turnouts. The prefix may not always be "M", MQTT connections do not have exclusive rights to the letter M so another connection may already have used "M".?

For the topic, I think there is general acceptance that we retain the existing topic syntax though allow the first two components can be user choice and number can be text of user choice.? I suggest Bob can decide whether or not it should include the two character prefix, currently it doesn't, perhaps it should. Technically, the first two topic levels (trains/track)?are actually the second and third levels, with the top level, the bit before the first slash, being null so that means we could use that extra level if we want without breaking compatibility with the existing structure. Sensors may need to be pinned down a bit more so that JMRI can be programmed to handle it.


For payloads, in the interests of keeping things simple and clear, I'm suggesting the payload be the state (or equivalent) as shown in JMRI,

Device type? -? ?Payload options
?
Turnout? ? - Closed | Thrown
Sensor? ? ?- Active | Inactive?
Light? ? ? ? -? On | Off?
Signal Head - Red | Yellow | Green | Lunar | Dark | Flashing Red | Flashing Yellow | Flashing Green | Flashing Lunar

This doesn't rule out extending this list to other items in future.
These could be simple text or in JSON form like {"state"="ACTIVE"}

I think this will get a lot of people a long way but there are cases where more complexity may be required. I think we're a long way from deciding what else people might want, where the information might be stored in JMRI? and what to do with it? so we may need to leave that for an "Advanced Settings" future option when people get a better idea of what is useful and how it will come together.?

The JMRI sensor handler can subscribe to "+/+/+/sensor/#"? to capture all sensor input.The topic level following "sensor" should match the hardware address for the relevant sensor.? The preceding levels can be used as optional filters if desired.??

I'm happy for other suggestions but we need to be specific so we have a tangible specification for programmers to work with.?

Kind regards, David.?


Locked Re: Decoder Pro problems

 

See below:

On 2 Jan 2019, at 6:39 PM, Peter Ross <peterr@...> wrote:

Could I just say that as a relative newcomer I still find the term "sheet" confusing. You obviously know what you mean but at best the word seems superfluous and at worst confusing. If you mean "read decoder", why not say so?
Because "read sheet" certainly does not mean "read decoder". It means read only those items on the current sheet/(mumble)/tab/(thingy you can see on screen)...

And for "write changes", why not something like "write changes to file".
Because "write changes", certainly does not mean "write changes to file". It means "write changes to decoder".

Read and Write are probably never used in relation to files in JMRI:
- Open and Save are usually used in relation to files.
- Read and Write are probably always used in relation to Decoder CVs.

Read and Write are usually qualified by terms such as changes/full/all/sheet to
indicate the scope of changes.

If I recall correctly "sheet" is mentioned four times with what seem to be four different meanings.
I've never seen more than one meaning for "sheet" in JMRI. Can you explain further?

Dave in Australia


Locked Re: Decoder Pro problems

 

(mumbles) are often called "tabs", particularly in Microsoft and Apple documentation. This probably comes from often being rendered by those platforms like the paper tabs usually attached to the top of real paper sheets and/or folders in a filing cabinet.

The term "sheet" may come from the filing cabinet analogy, or from the term "worksheet" used in Microsoft Excel.

There may be official terminology guidelines but I haven't seen them.
--
Dave in Australia

On 4 Jan 2019, at 3:27 PM, Bob Jacobsen <rgj1927@...> wrote:

When you look at a decoder¡¯s values in JMRI, you¡¯ll see a stack of individual sets of values that can be selected by the tabs at the top.

What should we call those?

There¡¯s a (mumble) for basic motor options, another (mumble) for lights, another (mumble) for sounds, etc.


Locked Re: Roster Images Upside Down

 

Marc,

Not at all. The iPhone behaves just like a "real man's camera" (we have those too). The problem is with some image rendering software.

If you hold the iPhone in landscape mode with the main camera lens (we are not considering the selfie camera) in the top corner and the power button at the top, the iPhone considers that the "normal" orientation and sets the EXIF orientation flag to Horizontal Normal. Just like my "real man's camera" when I hold it the right way up.

If I rotate the iPhone 90 degrees clockwise it sets the EXIF orientation flag to Rotate 90 CW. Just like my "real man's camera" when I rotate it 90 degrees clockwise.

If I rotate the iPhone 180 degrees clockwise it sets the EXIF orientation flag to Rotate 180. Just like my "real man's camera" when I hold it upside down.

If I open any of these images with any image processing software I use on my Mac (or use Quick-Look to preview them), they all appear Right Way Up (the Mac software uses the EXIF orientation flag to render the images the way they should be viewed.)

If I drag any of the rotated images (iPhone or "real man's camera") to a Roster Media window in JMRI, they show as if I've been standing on my head or lying on one side.

There are no problems with the iPhone nor the "real man's camera". The problem is that whatever we use to render JPEG images in JMRI (on the Mac at least) ignores the EXIF orientation flag embedded in the image and doesn't render the image in its corrected orientation.

What are Windows and Linux users seeing?
--
Dave in Australia

On 4 Jan 2019, at 1:20 PM, Marc <forfoum@...> wrote:

Another interesting quirk that never popped up or reported. So if the person does not hold the IPhone in proper orientation, the EXIF data can get really confused... Was upright landscape or inverted landscape :-) I never use an Iphone for pictures, prefer a real mans camera :-).


Locked Re: Decoder Pro Terminology

 

To add to Ken¡¯s comments below, JMRI is already translated for UK users.

The changes include using railway instead of railroad, wagon instead of car, and spelling color, analogue, catalogue, signalling, neighbour and grey properly, etc. But there might be more than can be done.

See


for more info on this if you¡¯d like to make the translations better.

Bob

On Jan 3, 2019, at 8:27 PM, Ken Cameron <kcameron@...> wrote:


I think it is safe to say that JMRI is produced on the planet, the whole
planet. While the US may have the largest number of supporters, there is a
good number on the other parts of the planet. Some other most frequent
support people on this list are 'down under'. Other wrap around the globe.
The design ideas have always tried to 'think globally' when creating things.
In fact the titles you mention, like 'Write Changes on Sheet' are completely
translated for many different languages. As many of the labels you read are
in fact from a database the gives a translation for each language somebody
has taken the time to figure out the right words for that language.
--
Bob Jacobsen
rgj1927@...


Locked Re: Decoder Pro Terminology

 

Peter,

I think it is safe to say that JMRI is produced on the planet, the whole
planet. While the US may have the largest number of supporters, there is a
good number on the other parts of the planet. Some other most frequent
support people on this list are 'down under'. Other wrap around the globe.
The design ideas have always tried to 'think globally' when creating things.
In fact the titles you mention, like 'Write Changes on Sheet' are completely
translated for many different languages. As many of the labels you read are
in fact from a database the gives a translation for each language somebody
has taken the time to figure out the right words for that language.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org


Locked Re: Decoder Pro problems

 

When you look at a decoder¡¯s values in JMRI, you¡¯ll see a stack of individual sets of values that can be selected by the tabs at the top.

What should we call those?

There¡¯s a (mumble) for basic motor options, another (mumble) for lights, another (mumble) for sounds, etc.

Bob

On Jan 1, 2019, at 11:39 PM, Peter Ross <peterr@...> wrote:

Thanks Ken

Could I just say that as a relative newcomer I still find the term "sheet" confusing. You obviously know what you mean but at best the word seems superfluous and at worst confusing. If you mean "read decoder", why not say so? And for "write changes", why not something like "write changes to file". If I recall correctly "sheet" is mentioned four times with what seem to be four different meanings.

Not that I don't appreciate what you do for us, just saying that from this user's perspective the terminology is not helpful.

Regards

Peter


On 2/01/2019 5:29 PM, [email protected] wrote:
for each pane in the
decoder pages you would do a 'read sheet' first, then make your changes,
then do 'write changes on sheet' to update the decoder.
--
Bob Jacobsen
rgj1927@...


Locked Re: Trouble with JMRI to JMRI client/server

 

Replacing old analog panels (and all the associated relay wiring) with virtual panels at the East and West end of 60' yards.

The thought was to use Pi's and touch screens talking to a 'larger' computer running the layout with PanelPro.? The testing was at home using
the RPi 3 (a Locobuffer sim since it is not really connected to anything) as the main system talking across wireless to Pi zeros.??

The problem with the zero's is that the browser uses 100% of the cpu, and response time is poor for updates just talking to the JMRI Web server for our size layout (5k square with about 100 Loconet devices).? Older iPads etc. need to use frames rather than panels, another poor response time option.
So I loaded JMRI on to the zero's, which consumed only roughly 30-50% of the cpu.? Then the decision is which client/server protocol to use to get a JMRI yard panel 'subset', a single panel 'screen' to work on the zeros for the yard operators.? Those yard screens are actually iconified on the main computer that is running primarily for dispatching functions.??

I was not able to get a test using SImple Server, or Loconet only to work...though Bob's thought that the Loconet sim is not robust seemed to be the issue.

At the club I was able to get Loconet over TCP working with good response, i.e. real time updates of the same panels located on both machines.? I guess what I was looking for was the ability to 'allocate' sub panels to different devices that do not necessarily need to share all the table data, i.e. the yard switches (and associated panel and tables) do not have to be known/controlled by the dispatcher's instance of JMRI who is concerned about the mainline.

Might be asking for too much,

Thanks for your assistance,
Martin Booker


Locked Re: For Andrew (Andy) and his Walthers GP7

 

I'm only able to create an xml export file. How does one create a csv? Sorry, total newbie.?



On Thu, Jan 3, 2019 at 9:47 PM Andrew via Groups.Io <soundrew=[email protected]> wrote:
Hi Marc,?
A couple things first.....

The Power supply for the PR4 is 14.9v dc rated at 300 milliamps. The power supply for the DCS51 is actually lower voltage, not higher, at 13.8v but has an amperage of a whopping 3500ma! The terminals on these are positive tip, negative sleeve. I didn't have another ps to use so I just used the one for the DCS51 and, so far, I haven't let the smoke out of the PR4! I would suggest this cautiously as that is a huge amperage difference.?

Ive attached the PR4 to the program track and connected it to my computer. After starting a new profile in DP, I attempted to connect to the loco and when I hit read type, I got a message telling me to select from highlighted decoders (with a bunch of soundtraxx models highlighted in blue. I chose the one titled tsunami diesel genesis OEM as it seemed closest. I'm guessing I shouldn't have done this because it may be showing CVs from a different loco? Either way, I'm about to send you the csv file and I hope it's the info from my loco.?

Thanks,?

Andy



On Thu, Jan 3, 2019 at 8:50 PM Marc <forfoum@...> wrote:
On Thu, Jan 3, 2019 at 02:19 AM, Andrew wrote:
Hi Marc,
I've been getting conflicting info. Some say that you also program on the main using "blast" mode,
Yes and that is why I explicitly recommend you disconnect the layout from the Zephyr temporarily. Blast goes out on both the PROG and RAIL leads as I stated in my post further up the thread.

or get the PTB-100. It sounds like you're saying I should scrap the idea (at least for now)of using these components with the computer and just swicth the PR4 to programmer?
?
Not what I am saying. I am offering options if the Soundtraxx PTB-100 is not an investment you want to make then switching to the PR4 is an option if you have the 16-18 volt power pack in hand. Using the Digitrax provided PS14 MAY work, throw of the dice.

I run my PR3 from any power pack I have that is? up to the task.?
I run the PS14 if I am loading Digitrax SOUND files (SPJ)? into Digitrax decoders? simply because this is safer for the Digitrax Sound decoders.
I run the 15VAC/3A power pack or an 18VDC/4.5A power pack on the PR3 if I am programming other than Digitrax decoders (sound or not)? via the PR3 in Standalone mode.

Marc

--
Andrew Roberts Potomac Sound LLC PO Box 223 Monrovia, MD 21770-0223 (301) 332-6111 Andrew@...

--
Andrew Roberts Potomac Sound LLC PO Box 223 Monrovia, MD 21770-0223 (301) 332-6111 Andrew@...


Locked Re: For Andrew (Andy) and his Walthers GP7

 

Hi Marc,?
A couple things first.....

The Power supply for the PR4 is 14.9v dc rated at 300 milliamps. The power supply for the DCS51 is actually lower voltage, not higher, at 13.8v but has an amperage of a whopping 3500ma! The terminals on these are positive tip, negative sleeve. I didn't have another ps to use so I just used the one for the DCS51 and, so far, I haven't let the smoke out of the PR4! I would suggest this cautiously as that is a huge amperage difference.?

Ive attached the PR4 to the program track and connected it to my computer. After starting a new profile in DP, I attempted to connect to the loco and when I hit read type, I got a message telling me to select from highlighted decoders (with a bunch of soundtraxx models highlighted in blue. I chose the one titled tsunami diesel genesis OEM as it seemed closest. I'm guessing I shouldn't have done this because it may be showing CVs from a different loco? Either way, I'm about to send you the csv file and I hope it's the info from my loco.?

Thanks,?

Andy



On Thu, Jan 3, 2019 at 8:50 PM Marc <forfoum@...> wrote:
On Thu, Jan 3, 2019 at 02:19 AM, Andrew wrote:
Hi Marc,
I've been getting conflicting info. Some say that you also program on the main using "blast" mode,
Yes and that is why I explicitly recommend you disconnect the layout from the Zephyr temporarily. Blast goes out on both the PROG and RAIL leads as I stated in my post further up the thread.

or get the PTB-100. It sounds like you're saying I should scrap the idea (at least for now)of using these components with the computer and just swicth the PR4 to programmer?
?
Not what I am saying. I am offering options if the Soundtraxx PTB-100 is not an investment you want to make then switching to the PR4 is an option if you have the 16-18 volt power pack in hand. Using the Digitrax provided PS14 MAY work, throw of the dice.

I run my PR3 from any power pack I have that is? up to the task.?
I run the PS14 if I am loading Digitrax SOUND files (SPJ)? into Digitrax decoders? simply because this is safer for the Digitrax Sound decoders.
I run the 15VAC/3A power pack or an 18VDC/4.5A power pack on the PR3 if I am programming other than Digitrax decoders (sound or not)? via the PR3 in Standalone mode.

Marc

--
Andrew Roberts Potomac Sound LLC PO Box 223 Monrovia, MD 21770-0223 (301) 332-6111 Andrew@...


Locked Re: Decoder Pro Terminology

 

¿ªÔÆÌåÓý

Peter,

I think that is because JRMI is produced overseas.? As example was brought home to me at work today.? In Britain? what we call a Bandaid is called a plaster, In the general public in North America it is called a Bandaid, but in the medical field in Canada they are called bandages.

PaUL

On 1/1/2019 11:39 PM, Peter Ross wrote:

Thanks Ken

Could I just say that as a relative newcomer I still find the term "sheet" confusing. You obviously know what you mean but at best the word seems superfluous and at worst confusing. If you mean "read decoder", why not say so? And for "write changes", why not something like "write changes to file". If I recall correctly "sheet" is mentioned four times with what seem to be four different meanings.

Not that I don't appreciate what you do for us, just saying that from this user's perspective the terminology is not helpful.

Regards

Peter


On 2/01/2019 5:29 PM, [email protected] wrote:
for each pane in the
decoder pages you would do a 'read sheet' first, then make your changes,
then do 'write changes on sheet' to update the decoder.


Locked Re: Decoder Pro problems

 

Peter,

Some of the terms are old terms. In the beginning the instruction 'sheets'
for a decoder had the data split up a bit and the name 'sheet' stuck, at
least that how it seemed to me. I tend to use term like 'tab' or 'pane', the
last one is more a programmer term for the way the graphic works. Early
decoders had only one or two pages, now they make small books, if you ever
got one printed out in total.

The other issue with the decoders are you have to write your data to the
decoder, then you want to save your data to the file, so two quite different
operations.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org


Locked Re: Decoder Pro problems

Peter Ross
 

Thanks Ken

Could I just say that as a relative newcomer I still find the term "sheet" confusing. You obviously know what you mean but at best the word seems superfluous and at worst confusing. If you mean "read decoder", why not say so? And for "write changes", why not something like "write changes to file". If I recall correctly "sheet" is mentioned four times with what seem to be four different meanings.

Not that I don't appreciate what you do for us, just saying that from this user's perspective the terminology is not helpful.

Regards

Peter


On 2/01/2019 5:29 PM, [email protected] wrote:

for each pane in the
decoder pages you would do a 'read sheet' first, then make your changes,
then do 'write changes on sheet' to update the decoder.


Locked Re: JMRI Not Identifying Locomotives Properly

 

¿ªÔÆÌåÓý

dcesharkman,

Give me some time to mull over this one; applicability, practicality, potential benefit to others in the user community, possible unintended impacts on other users, etc.

I need to spend some time with family responsibilities and having some down time...

--?
Dave in Australia

On 4 Jan 2019, at 4:54 AM, dcesharkman via Groups.Io <dcesharkman@...> wrote:

Perhaps there is a solution by looking at the User1 and User2 settings for differentiation? That maybe a good compromise solution. I could then go back to the duplicate numbers and give them different values in the user cv's to correct the issue.?


Locked Re: Ops and Roster question

 

To track what is an analog loco, the only meaningful data is the roster pane
and basic for address zero at the beginning of whatever decoder you pick.
The only way to carry the data over to a real decoder entry would be
cut/paste.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org


Locked Re: Trying to get on top of jython

 

Hi Bob,

It's 4.14 (I'm on Linux Mint 18.3), and no, I did not mess with properties. I'm no believer in fresh downloads, but if you think it's any use I'll happily try it - just let me know. I've also got 4.12 still ready to run. Up to yesterday, it gave me all the same results as 4.14 did, and I've more or less let that branch of investigation go.

I'll look at Dave Sands approach tomorrow or the day after (big shopping day tomorrow) and see if that'll work for me. My problem is that if a totally valid approach does not work, then my trust in 'it' (in this case python) goes swiftly down the drain.

<rant ignore=true>
Where are the good old days of reliable software (C compilers just didn't go wrong or if they did it got fixed)... I know - complexity... I chucked my job because I positively hated having to work with javascript, bane of my professional life. I chucked Windows because over 90% of my time over the last three years was spent doing system maintainance and problem seeking (what a relief Linux is)! And now I want to spend my time enjoying railway automation with JMRI, and railway film editing/DVD production, which Windows also killed and I need to get that started from scratch on Linux. In short, I am in really desperate need of some success, and will fight tooth and nail to get there!
</rant>

I'm very grateful for the help I get here - this community is as supportive as they come. I am already way beyond where I'd ever have been without you.
Wouter


On Thu, 3 Jan 2019 at 20:25, Bob Jacobsen <rgj1927@...> wrote:
Thanks.

Wouter, what version of JMRI are you using?

Re this:

> 3) util.py
> Totally useless as is, but that's because it has been pruned of everything that could go while still showing the bug. As uploaded, it works, but only because of the assignment statement that creates a valid 'masts' variable. Comment that out, and things go horribly wrong, which they shouldn't if masts were properly preset. Also, edit a signalmast name into this file that is a valid one in your panelfile, instead of EastNorthOuter. I've also included my panelfile, should that be handier to use instead.

I simply don¡¯t understand this at all.? The comment says that the print statement shows in the log, but there¡¯s nothing to invoke it. With the masts assignment commented or not, I get:

masts= jmri.managers.DefaultSignalMastManager@2f7c2f4f

so something else is going on in your installation.

Have you messed with the python.properties file? (Whether or not you have, the right answer is ¡°don¡¯t¡±)

Bob



> On Jan 3, 2019, at 12:10 PM, Dave Sand <ds@...> wrote:
>
> Bob,
>
> The directory is up one level.
>
> Dave Sand
>
>
>> On Jan 3, 2019, at 2:06 PM, Bob Jacobsen <rgj1927@...> wrote:
>>
>> I¡¯m not seeing that directory.? Link please?
>>
>> What may be going on here is the scope of global variables:?
>>
>> Bob
>>
>>> On Jan 3, 2019, at 8:14 AM, whmvd <vandoornw@...> wrote:
>>>
>>> I've now created a WoutersPythonbug directory in ProblemsBeingWorkedOn which contains just three tiny scripts, together showing that there is, as far as I can make out, really a bug here.
>>>
>>
>> --
>> Bob Jacobsen
>> rgj1927@...
>>
>>
>>
>>
>>
>>
>
>
>
>

--
Bob Jacobsen
rgj1927@...