Locked
Re: Maybe the last test version before 1.1?
Re ops mode below, it worked perfectly with a Chief system and
Sountraxx in a Proto2000 0-8-0 - really nice to set the engine
running in a loop, change the sound parameters and immediately hear
the differences, all just by clicking buttons on the screen and
moving sliders. Thanks for the report. I was getting a little nervous that it just completely failed to work... Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Maybe the last test version before 1.1?
The new version has worked without any problems for me so far (not a huge amount of testing) Re ops mode below, it worked perfectly with a Chief system and Sountraxx in a Proto2000 0-8-0 - really nice to set the engine running in a loop, change the sound parameters and immediately hear the differences, all just by clicking buttons on the screen and moving sliders. Thanks, keep up the good work! --- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote: I've just posted what I really hope is the last test version before
JMRI/DecoderPro 1.1
--snip--
A) Ops mode for NCE, EasyDCC and Lenz. (Ops mode for Digitrax made
an appearance in 1.0.7, and I've not yet heard any reports of
whether it works OK or not)
|
Locked
Re: Maybe the last test version before 1.1?
Just loaded version 1.08 and I must say it gets better and better. I've
only tested that one save bug so far and it seems ok. Subtle changes to the
look but I like them.
Looked at the speedometer and wonder where it's written up. What do I
use for sensors or does this require a program (RR&Co. for example) to run?
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief/Zephyr systems
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: Handling changes to the short-address CV
Bob/John, Unless soemone has opportunity and presents information on John's comments before the weekend arrive's, I'll go out on a limb this weekend and program a short address on the best running engine in my fleet so this concern can be tested. Bob --- In jmriusers@y..., "John Deecker" <jdeecker@a...> wrote: Bob ....
If I understand this correctly, you will force a write to CV29 and BEMF settings whenever the short address is changed / written. ......... Have you tested this procedure? It has been my understanding that the DZ121 will reset theses CVs the next time it is put on fulll DCC powered track after the CV1 has been written. Even if you write to these CVs while on the programming track, they will be reset again when the decoder is moved to the main DCC power track.
I have not actually done this in some time, ( I avoid using this
decoder because of this problem) but as I remember it, the required procedure is write CV1, then move the loco to full powered track (CVs will be reset), then back to the program track and overwrite the the affected CVs with the desired values.
|
Locked
Re: Handling changes to the short-address CV
At 10:52 AM -0400 10/17/02, John Deecker wrote: Bob ....
If I understand this correctly, you will force a write to CV29 and BEMF settings whenever the short address is changed / written. ......... Have you tested this procedure? It has been my understanding that the DZ121 will reset theses CVs the next time it is put on fulll DCC powered track after the CV1 has been written. Even if you write to these CVs while on the programming track, they will be reset again when the decoder is moved to the main DCC power track.
I have not actually done this in some time, ( I avoid using this decoder because of this problem) but as I remember it, the required procedure is write CV1, then move the loco to full powered track (CVs will be reset), then back to the program track and overwrite the the affected CVs with the desired values. It certainly possible that the DZ121 will still continue to act weirdly. I borrowed one for some tests before writing this code, but no longer have it. I've tried it on several other decoders, and it seems to do the right thing for them. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
At 8:49 AM -0400 10/17/02, john donaldson wrote: One question, I have the digitrax Genious starter
system, using the DB-50 command system. This is the command system
that does not have a seperate programming track output.
Does you program still work with it correctly, assuming that
you only have one engine on the track at a time. I have never tested this myself, so I'm not 100% sure. But people have been using Empire Builder command station with DecoderPro, and it works. Note that you'll still not be able to read the contents of decoders. That's a limitation of the hardware, not something the program can do anything about. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Handling changes to the short-address CV
Bob ....
If I understand this correctly, you will force a write to CV29 and BEMF settings whenever the short address is changed / written. ......... Have you tested this procedure? It has been my understanding that the DZ121 will reset theses CVs the next time it is put on fulll DCC powered track after the CV1 has been written. Even if you write to these CVs while on the programming track, they will be reset again when the decoder is moved to the main DCC power track.
I have not actually done this in some time, ( I avoid using this decoder because of this problem) but as I remember it, the required procedure is write CV1, then move the loco to full powered track (CVs will be reset), then back to the program track and overwrite the the affected CVs with the desired values.
John
John and Sandi Deecker jdeecker@...
Hemlock Junction Railroad 150 Mill St Milton ON L9T 1S2
DCC, HO, N & G model railroad supplies
toggle quoted message
Show quoted text
----- Original Message -----
From: Bob Jacobsen
To: jmriusers@...
Sent: Wednesday, October 16, 2002 11:49 AM
Subject: [jmriusers] Handling changes to the short-address CV
I'd like to describe a way for DecoderPro to handle the side-effects
of changing CV1, the short address CV. I'd really appreciate hearing
whether people think this will do what they want. I'd also like to
hear whether we should change an aspect of the color coding.
In many decoders, when you change CV1 other CV values change. The
NMRA specs state that CV29 and CV19 should be changed so that command
stations that can't change these directly can count on particular
values. (None of the ones that DecoderPro works with have this
limitation, but we still have to deal with the side-effects of the
weird parts of the NMRA spec). Some decoders reset additional CVs,
e.g. the DZ121 resets it's BEMF settings.
To fix this, I've introduced a "short address variable" type that
will handle it as a special case. This will allow us to specify the
correct CVs to change, etc, in the decoder definition file.
When the program writes the short address to the decoder, it will
also mark the other values as "edited" so the program thinks they
need to be written. This will write the _desired_ values, not the
default values, so the decoder will be restored to the "intended"
contents even though the short-address write has changed them.
For this to work, the panes containing modified values have to have
"write sheet" pressed, or "write all" has to be pressed. If you try
to close the window before doing that, you'll be reminded that some
values haven't been written to the decoder. (Until recently there
was a bug in this logic; I think that is now fixed)
Currently, a yellow color for a value indicates both "read from file,
not known to be the same as in the decoder" and "edited, not yet
written". (Red means "error writing or reading, value in decoder
unknown"; white means "value known to be the same as the decoder due
to having done a read or write") Perhaps it would be clearer to
people if those two states were different colors. Then you could
recognize the "edited" state, which generally means "you have to
write this before the change takes effect". Would orange be a good
color for that?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Maybe the last test version before 1.1?
I've just posted what I really hope is the last test version before JMRI/DecoderPro 1.1
The 1.1 version, with CDs, etc, was supposed to be out by October 10th, and I'm well behind where I should be on that. There have been a lot of changes (improvements?) recently, but it's time to call a halt to all that, make sure that the serious bugs are fixed, and get 1.1 out for the general user.
This test version contains:
1) Programmer mode selection now goes through a separate pane, rather than being a bunch of radio buttons in your face.
2) CV1 handling improved
3) Update the version numbers in decoder files, so more likely to get them right
4) Many bugs fixed, including contributions from Sip Bosch and Robin Becker
5) Speedometer improved by Roger Gleason
6) Mike Davison fixed a problem with ID of Soundtraxx decoders
7) Digitrax CS decoders now include BEMF (as they should have all along)
It does _not_ contain:
A) Ops mode for NCE, EasyDCC and Lenz. (Ops mode for Digitrax made an appearance in 1.0.7, and I've not yet heard any reports of whether it works OK or not)
Or any of the other great suggestions for new capabilities.
The Windows installer can be downloaded from:
I would _really_ appreciate hearing from people who try this. I'll put together a Mac update ASAP, hopefully tonight, and post a note when that's done. I'd very much like to update the READMEs, etc, over the weekend and make this the 1.1 version for the general user, but to do that I need to hear from a couple of people that it's working.
Thanks in advance
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Handling changes to the short-address CV
On Thu, 17 Oct 2002 04:36:41 -0700
Bob Jacobsen <Bob_Jacobsen@...> wrote:
Bob,
One question, I have the digitrax Genious starter system,
using the DB-50 command system. This is the command system that does not have a seperate programming track output. Does
you program still work with it correctly, assuming that you
only have one engine on the track at a time.
John Donaldson
|
Locked
Re: Handling changes to the short-address CV
At 9:48 AM +1300 10/17/02, Alex Shepherd wrote: Would it be possible/practical to include all the relavent CVs on the same
tab pane so that when you change the CV1 you will see the others change as
well. Maybe allow these associated CVs to be on more than one pane so they
are in their natural grouping pane and also all together on the CV1 pane so
you can more easily see what is going on. For most decoders, we've already got that. The exception is just the Digitrax DZ121 as far as I know. That one zeros it's BEMF values when you write the short address. I'd rather not put those on the Basic pane; they're really not basic. Since it's just that one obscure decoder, I think it's probably best to leave those CVs off the Basic pane. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Handling changes to the short-address CV
At 1:15 PM -0700 10/16/02, Mark Gurries wrote: Bob Jacobsen wrote:
>Currently, a yellow color for a value indicates both "read from file,
not known to be the same as in the decoder" and "edited, not yet >written". ... Perhaps it would be clearer to
>people if those two states were different colors. Then you could
recognize the "edited" state, which generally means "you have to
write this before the change takes effect". Would orange be a good
color for that?
How about flashing yellow? Catches the eye easily and works for color
blind people. Unfortunately, flashing is hard to do. You have to manually program the on/off cycle, as the look&feel support doesn't have flashing built in. But this is fortunate, in a way, as screens with lots of flashing text seem pretty hard to read. Color blindness is a real concern, which is why we don't use green to indicate anything. The green/yellow distinction on a LCD is particularly hard for too many people. But orange/yellow seems OK, esp. when both are visible. The other part is to let the user know they need to make the save. Perhaps flash or highlight the write buttons under these conditions so
one does not have to hunt down the pane involved. Coloring the write buttons is a good idea. I'll look into that. Bob -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Locked
Re: Handling changes to the short-address CV
When the program writes the short address to the decoder, it will
also mark the other values as "edited" so the program thinks they
need to be written. This will write the _desired_ values, not the
default values, so the decoder will be restored to the "intended"
contents even though the short-address write has changed them. Bob, Would it be possible/practical to include all the relavent CVs on the same tab pane so that when you change the CV1 you will see the others change as well. Maybe allow these associated CVs to be on more than one pane so they are in their natural grouping pane and also all together on the CV1 pane so you can more easily see what is going on. For this to work, the panes containing modified values have to have
"write sheet" pressed, or "write all" has to be pressed. If you try
to close the window before doing that, you'll be reminded that some
values haven't been written to the decoder. (Until recently there
was a bug in this logic; I think that is now fixed) If they are all on ehte same pane, when you do a "write pane" you will get all the CVs you need in one go. Cheers Alex
|
Locked
Re: Handling changes to the short-address CV
Bob Jacobsen wrote:
Currently, a yellow color for a value indicates both "read from file,
not known to be the same as in the decoder" and "edited, not yet
written". (Red means "error writing or reading, value in decoder
unknown"; white means "value known to be the same as the decoder due
to having done a read or write") Perhaps it would be clearer to
people if those two states were different colors. Then you could
recognize the "edited" state, which generally means "you have to
write this before the change takes effect". Would orange be a good
color for that?
How about flashing yellow? Catches the eye easily and works for color blind people. The other part is to let the user know they need to make the save. Perhaps flash or highlight the write buttons under these conditions so one does not have to hunt down the pane involved. Best Regards, Mark Gurries Linear Technology Power Supply & Battery charger Applications Engineer/Manager --------------------------------------------------------- Model Railroad Club and NMRA DCC presentations are at: -------------------------------------------------------- Audio Enthusiast (Love SAE equipment) ----------------------------------------------------------
|
Locked
Re: EasyDCC serial cable?
I use a DB-9 to RJ-45 connector for hooking my laptop up to the console
ports of Cisco Routers, so I know those are readily available. The newer
Cisco's serial ports are RJ-45 connectors. Is the EasyDCC serial port a
RJ-11/12 or RJ45? I also have some _really old_ DB-25 to RJ-12 from a
company called "Custom Cable Industries".
Mike M.
toggle quoted message
Show quoted text
-----Original Message-----
From: Bob Jacobsen [mailto:Bob_Jacobsen@...]
Sent: Wednesday, October 16, 2002 8:38 AM
To: jmriusers@...
Subject: [jmriusers] EasyDCC serial cable?
Is there a good source for an EasyDCC-compatible serial cable?
Somebody asked me where to get a cable to hook a DB9 serial port from
a computer to the telephone-style connector on the EasyDCC command
station. I don't know of a source, other than soldering one up.
Is there a place to get them premade?
Thanks
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Locked
Handling changes to the short-address CV
I'd like to describe a way for DecoderPro to handle the side-effects of changing CV1, the short address CV. I'd really appreciate hearing whether people think this will do what they want. I'd also like to hear whether we should change an aspect of the color coding.
In many decoders, when you change CV1 other CV values change. The NMRA specs state that CV29 and CV19 should be changed so that command stations that can't change these directly can count on particular values. (None of the ones that DecoderPro works with have this limitation, but we still have to deal with the side-effects of the weird parts of the NMRA spec). Some decoders reset additional CVs, e.g. the DZ121 resets it's BEMF settings.
To fix this, I've introduced a "short address variable" type that will handle it as a special case. This will allow us to specify the correct CVs to change, etc, in the decoder definition file.
When the program writes the short address to the decoder, it will also mark the other values as "edited" so the program thinks they need to be written. This will write the _desired_ values, not the default values, so the decoder will be restored to the "intended" contents even though the short-address write has changed them.
For this to work, the panes containing modified values have to have "write sheet" pressed, or "write all" has to be pressed. If you try to close the window before doing that, you'll be reminded that some values haven't been written to the decoder. (Until recently there was a bug in this logic; I think that is now fixed)
Currently, a yellow color for a value indicates both "read from file, not known to be the same as in the decoder" and "edited, not yet written". (Red means "error writing or reading, value in decoder unknown"; white means "value known to be the same as the decoder due to having done a read or write") Perhaps it would be clearer to people if those two states were different colors. Then you could recognize the "edited" state, which generally means "you have to write this before the change takes effect". Would orange be a good color for that?
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Is there a good source for an EasyDCC-compatible serial cable?
Somebody asked me where to get a cable to hook a DB9 serial port from a computer to the telephone-style connector on the EasyDCC command station. I don't know of a source, other than soldering one up.
Is there a place to get them premade?
Thanks
Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
I think I've finally tracked down the cause of this. Under obscure circumstances, default values in the decoder definition file would result in some CV variables being marked as "editted" when the programming frame was first opened. The program them thought that a person had changed them, even though they were just the default values. And much confusion would ensue. I'm testing a fix. Bob At 10:40 AM -0700 9/30/02, Jon Miller wrote: Test done with fresh T1 decoder.
Use programming track.
Paged Mode
Decoder installed, Ident.
Found mfg 153 (TCS) version 22 not defined
Changed to T1 and opened Programmer
In roster Entry changed ID to 1234 and did a save.
Went to Basic pane and changed long address to 1234, checked Extended
Addressing and did write sheet.
Colors changed from yellow to red to white as normal.
Went to roster entry and did a save.
When I tried to exit program got the “some changes have not been written"
window.
Closed window anyway!
--closed the program.
Reopened the program.
Went through the above steps except didn’t do roster entry.
1234 showed in Long address but not in DCC Address and Extending addressing
box was not checked, tried to exit but program hung.
Reopened the program and went through above step except for two differences;
used 1235 number and did a read of all panes. This time program closed as
it should.
When I reopened program old message was at the bottom found mdg 153 etc.
I 'quit' the program and reopened. Now it came up in idle. Went through
the same above and went to basic pane, the address had not changed.
At this point I decided to reload the program.
Went through above steps but this time used engine number id, it was there
and showed engine 1235.
?? It's not working like it did but I can't exactly define what's wrong
other than above comments.
Jon Miller
AT&SF
For me time has stopped in 1941
Digitrax DCC owner, Chief system
NMRA Life member #2623
Member SFRH&MS
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to -- -------------- Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
|
Well we need to break the problem down
First check that the LocoBuffer works with John's RRCTRL program. Download
it from:
Connect it up with the same cable and make sure it works. Do things like:
- Open the Debug windows and make sure messages are recived when you do
things with the throttle.
- Make sure you can turn the Layout power on with it or open a throttle
windows and control a loco.
This should verify your hardware and note the baud rate used and use this
with DecoderPro later.
If you cannot get this to go then you need to double check the LB jumpers. I
recently helped someone else who had the LB in MS100 mode. Half way down the
page there are some notes about LB jumpers here:
Once you can verify the LB and the PC connection then try again with
DecoderPro and use the same baud rate that your LB jumpers are configured
for and enable hardware handshake.
Hope this helps
Alex
toggle quoted message
Show quoted text
----- Original Message ----- From: "Wendell Camp" <wendellcamp@...> To: <jmriusers@...> Sent: Tuesday, October 15, 2002 12:17 PM Subject: Re: [jmriusers] decoder pro Alex I reinstalled decoder pro and now can pick my ports . I get a message that loco buffer is not receiving data to check connection and cycle loco buffer power
----- Original Message -----
From: Alex Shepherd
Sent: Monday, October 14, 2002 6:36 PM
To: jmriusers@...
Subject: Re: [jmriusers] decoder pro
This is a bit strange as the DecoderPro installer pretty much gets it
right now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value
should be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to
|
Alex I reinstalled decoder pro and now can pick my ports . I get a message that loco buffer is not receiving data to check connection and cycle loco buffer power
toggle quoted message
Show quoted text
----- Original Message -----
From: Alex Shepherd
Sent: Monday, October 14, 2002 6:36 PM
To: jmriusers@...
Subject: Re: [jmriusers] decoder pro
This is a bit strange as the DecoderPro installer pretty much gets it right
now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since
you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value should
be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
|
This is a bit strange as the DecoderPro installer pretty much gets it right
now.
What OS and version of JAva are you using?
Do you have more than one version of Java or have you reinstalled Java since
you installed DecoderPro? If so reinstall DecoderPro again.
That is almost always because it has installed the Java commapi files into
the wrong locations.
There are two ways to resolve this:
1) The simple way is to uninstall DecoderPro and all installed versions of
the Java SDK and JRE. Then only install the most recent JDK/JRE which ever
you are using and then reinstall DecoderPro. Depending on you installation
you might not want to do this as it may bereak other Java packages.
2) The more difficult way is to fix the problem without removing anything:
- First work out which Java VM (if there are several) is being used by
DecoderPro and then you need to find out where it's files are on your disk.
To do this open a command shell and type:
java -version <ENTER>
and it should display its version string like:
H:\>java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Then using this version information look in the registry to find an entry
for:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
Then under that there is an entry for the "CurrentVersion" The value should
be something like 1.3 and then look below it and you will find more nodes
that match like:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.3
Under there will be a "JavaHome" entry that specifies where the files are.
Now go and download the Java Communication API from here:
and install it according to the instructions. Pay particular attention to
the place they say to instal the files as it will not work if you get it
wrong.
(Guess how I know how to fix this......)
Cheers
Alex
|
Bob Jacobsen