time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

SRS PRS10 repair

BM
Brian M
Fri, Aug 21, 2015 11:26 PM

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even at
varying baud rates). Lamp isn't lit. Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are common failure modes?
Anything match up with what I describe? Voltages to check would be helpful.
The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect
the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian
Dear list - I have come into possession of a for parts prs 10. I'd like to try to repair this device. What I've noticed so far. Serial is garbled. (Even at varying baud rates). Lamp isn't lit. Doesn't look great. I'd like to know if anybody else has wandered down this path. What are common failure modes? Anything match up with what I describe? Voltages to check would be helpful. The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect the crystal is fine. Thanks in advance. Happy hacking! - Brian
BC
Bob Camp
Sat, Aug 22, 2015 1:40 AM

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the diagnostic
info you need to go further. Garbled serial is better than none at all. It suggests
something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even at
varying baud rates). Lamp isn't lit. Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are common failure modes?
Anything match up with what I describe? Voltages to check would be helpful.
The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect
the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi On any microprocessor based gizmo, getting the micro running (again) is generally priority number one. It sets everything up and gives you the diagnostic info you need to go further. Garbled serial is better than none at all. It suggests something short of a total MCU death spiral … Bob > On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: > > Dear list - > > I have come into possession of a for parts prs 10. I'd like to try to > repair this device. What I've noticed so far. Serial is garbled. (Even at > varying baud rates). Lamp isn't lit. Doesn't look great. I'd like to know > if anybody else has wandered down this path. What are common failure modes? > Anything match up with what I describe? Voltages to check would be helpful. > The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect > the crystal is fine. > > Thanks in advance. Happy hacking! > - Brian > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
MC
Mike Cook
Sat, Aug 22, 2015 4:38 PM

Le 22 août 2015 à 03:40, Bob Camp kb8tq@n1k.org a écrit :

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the diagnostic
info you need to go further. Garbled serial is better than none at all. It suggests
something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even at
varying baud rates).

You don’t say how you are connecting to the Rb. The manual states:
"RS-232 data is sent to the host on pin 4, received from the host on pin 7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The transmit drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These levels are compatible with
most RS-232 line receivers, but does not require their use (a TTL inverter may be used
instead), hence simplifies the interface when used inside an instrument at the sacrifice of
degraded noise immunity over long lines."

So make sure that you adhere to that.

Lamp isn't lit.

What’s the date code. Early versions may be reaching EOL, though 20yrs id quoted.

Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are common failure modes?
Anything match up with what I describe? Voltages to check would be helpful.
The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect
the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin

> Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : > > Hi > > On any microprocessor based gizmo, getting the micro running (again) is > generally priority number one. It sets everything up and gives you the diagnostic > info you need to go further. Garbled serial is better than none at all. It suggests > something short of a total MCU death spiral … > > Bob > >> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: >> >> Dear list - >> >> I have come into possession of a for parts prs 10. I'd like to try to >> repair this device. What I've noticed so far. Serial is garbled. (Even at >> varying baud rates). You don’t say how you are connecting to the Rb. The manual states: "RS-232 data is sent to the host on pin 4, received from the host on pin 7. The baud rate is fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR or CTS controls are used; rather, the XON/XOFF protocol has been implemented. The transmit drive level is 0 and 5 V, not the +/-12 V normally associated with RS-232. These levels are compatible with most RS-232 line receivers, but does not require their use (a TTL inverter may be used instead), hence simplifies the interface when used inside an instrument at the sacrifice of degraded noise immunity over long lines." So make sure that you adhere to that. >> Lamp isn't lit. What’s the date code. Early versions may be reaching EOL, though 20yrs id quoted. >> Doesn't look great. I'd like to know >> if anybody else has wandered down this path. What are common failure modes? >> Anything match up with what I describe? Voltages to check would be helpful. >> The 10MHz out looked okay on a scope. Haven't gone further yet. I suspect >> the crystal is fine. >> >> Thanks in advance. Happy hacking! >> - Brian >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin
BM
Brian M
Tue, Aug 25, 2015 4:40 AM

I tried through the weekend, double and triple checking wiring and setup.
I've tried the following methods of getting serial comms working:
PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
PRS10 -> Level Shifter -> BBB UART
PRS10 -> MAX232 -> USB Serial adapter

Shortly after power is applied to the PRS10, I do get a string of
characters. Believe it should be the model information. Instead I get:
wy+VPgy

I guess the good news is that this output appears consistent with each
power cycle of the device. And I'm getting the same results through all the
hookup methods I've tried.

My minicom settings are for software flow control at 9600 8N1 - from what
the manual states, this should be the right settings. I've tried screen as
well - and get the same text. I went crazy trying several other rates and
setting combinations. No luck.

Maybe I've missed something obvious.

I agree that getting comms going to the MCU are going to be an important
step. How do people address this type of problem? Scope the serial and try
to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
further steps people try after that? If nothing else I think there's some
interesting stuff to learn here. I also wouldn't mind tearing out the
electronics, determining if the lamp is good, and attempt to build from
there. I don't know the datecode for the unit, the PCB is marked with a
datecode suggesting 2003? I don't have the full case. I'm trying to assess
what are reasonable next steps. How do I determine if the MCU is healthy?
If the MCU is fried, how do I determine if I just need to squeeze a new MCU
board in there?

Thanks! I appreciate the input so far!

  • Brian

PS - after looking again at the signal on the scope, it does seem like it
is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
what I saw on the main connector.

On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.cook@sfr.fr wrote:

Le 22 août 2015 à 03:40, Bob Camp kb8tq@n1k.org a écrit :

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the

diagnostic

info you need to go further. Garbled serial is better than none at all.

It suggests

something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even

at

varying baud rates).

You don’t say how you are connecting to the Rb. The manual states:
"RS-232 data is sent to the host on pin 4, received from the host on pin
7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR
or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The transmit
drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These levels are
compatible with
most RS-232 line receivers, but does not require their use (a TTL inverter
may be used
instead), hence simplifies the interface when used inside an instrument at
the sacrifice of
degraded noise immunity over long lines."

So make sure that you adhere to that.

Lamp isn't lit.

What’s the date code. Early versions may be reaching EOL, though 20yrs id
quoted.

Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are common failure

modes?

Anything match up with what I describe? Voltages to check would be

helpful.

The 10MHz out looked okay on a scope. Haven't gone further yet. I

suspect

the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to

and follow the instructions there.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to

and follow the instructions there.

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une
petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

I tried through the weekend, double and triple checking wiring and setup. I've tried the following methods of getting serial comms working: PRS10 -> Arduino Uno (with processor bypassed) -> USB Host PRS10 -> Level Shifter -> BBB UART PRS10 -> MAX232 -> USB Serial adapter Shortly after power is applied to the PRS10, I do get a string of characters. Believe it should be the model information. Instead I get: wy+VPgy I guess the good news is that this output appears consistent with each power cycle of the device. And I'm getting the same results through all the hookup methods I've tried. My minicom settings are for software flow control at 9600 8N1 - from what the manual states, this should be the right settings. I've tried screen as well - and get the same text. I went crazy trying several other rates and setting combinations. No luck. Maybe I've missed something obvious. I agree that getting comms going to the MCU are going to be an important step. How do people address this type of problem? Scope the serial and try to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there further steps people try after that? If nothing else I think there's some interesting stuff to learn here. I also wouldn't mind tearing out the electronics, determining if the lamp is good, and attempt to build from there. I don't know the datecode for the unit, the PCB is marked with a datecode suggesting 2003? I don't have the full case. I'm trying to assess what are reasonable next steps. How do I determine if the MCU is healthy? If the MCU is fried, how do I determine if I just need to squeeze a new MCU board in there? Thanks! I appreciate the input so far! - Brian PS - after looking again at the signal on the scope, it does seem like it is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like what I saw on the main connector. On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote: > > > Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : > > > > Hi > > > > On any microprocessor based gizmo, getting the micro running (again) is > > generally priority number one. It sets everything up and gives you the > diagnostic > > info you need to go further. Garbled serial is better than none at all. > It suggests > > something short of a total MCU death spiral … > > > > Bob > > > >> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: > >> > >> Dear list - > >> > >> I have come into possession of a for parts prs 10. I'd like to try to > >> repair this device. What I've noticed so far. Serial is garbled. (Even > at > >> varying baud rates). > > You don’t say how you are connecting to the Rb. The manual states: > "RS-232 data is sent to the host on pin 4, received from the host on pin > 7. The baud rate is > fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR > or CTS controls are > used; rather, the XON/XOFF protocol has been implemented. The transmit > drive level is 0 > and 5 V, not the +/-12 V normally associated with RS-232. These levels are > compatible with > most RS-232 line receivers, but does not require their use (a TTL inverter > may be used > instead), hence simplifies the interface when used inside an instrument at > the sacrifice of > degraded noise immunity over long lines." > > So make sure that you adhere to that. > > > >> Lamp isn't lit. > > What’s the date code. Early versions may be reaching EOL, though 20yrs id > quoted. > > >> Doesn't look great. I'd like to know > >> if anybody else has wandered down this path. What are common failure > modes? > >> Anything match up with what I describe? Voltages to check would be > helpful. > >> The 10MHz out looked okay on a scope. Haven't gone further yet. I > suspect > >> the crystal is fine. > >> > >> Thanks in advance. Happy hacking! > >> - Brian > >> _______________________________________________ > >> time-nuts mailing list -- time-nuts@febo.com > >> To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une > petite et provisoire sécurité, ne méritent ni liberté ni sécurité." > Benjimin Franklin > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >
BI
Brian Inglis
Tue, Aug 25, 2015 4:23 PM

Hi,
You have too many 1s in your startup string compared to the expected "PRS_10\r".
If the MCU clock is not 10Mhz then the integrated UART rates will be off,
which should produce framing errors, but do UARTs still detect and systems
report these nowadays, or just pass along garbled data?
Otherwise, garbled data is most often a result of inadequate pin contact,
if the connectors are not seated properly, or the pins or sockets are loose
in their shells.
Age and rough treatment can have that effect.

"Internal hardware jumpers allow these pins to be configured as analog outputs
to monitor the lamp intensity and varactor voltage for complete compatibility
with the FRS."
Have you checked the jumpers in the manual Configuration Notes:
"Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data.
Many system parameters (including the lamp intensity) may be monitored via the RS-232
interface. The function of this pin may be changed to an analog monitor for the lamp
intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348)
on the microcontroller PCB."

On 2015-08-24 22:40, Brian M wrote:

I tried through the weekend, double and triple checking wiring and setup.
I've tried the following methods of getting serial comms working:
PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
PRS10 -> Level Shifter -> BBB UART
PRS10 -> MAX232 -> USB Serial adapter

Shortly after power is applied to the PRS10, I do get a string of
characters. Believe it should be the model information. Instead I get:
wy+VPgy

I guess the good news is that this output appears consistent with each
power cycle of the device. And I'm getting the same results through all the
hookup methods I've tried.

My minicom settings are for software flow control at 9600 8N1 - from what
the manual states, this should be the right settings. I've tried screen as
well - and get the same text. I went crazy trying several other rates and
setting combinations. No luck.

Maybe I've missed something obvious.

I agree that getting comms going to the MCU are going to be an important
step. How do people address this type of problem? Scope the serial and try
to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
further steps people try after that? If nothing else I think there's some
interesting stuff to learn here. I also wouldn't mind tearing out the
electronics, determining if the lamp is good, and attempt to build from
there. I don't know the datecode for the unit, the PCB is marked with a
datecode suggesting 2003? I don't have the full case. I'm trying to assess
what are reasonable next steps. How do I determine if the MCU is healthy?
If the MCU is fried, how do I determine if I just need to squeeze a new MCU
board in there?

Thanks! I appreciate the input so far!

  • Brian

PS - after looking again at the signal on the scope, it does seem like it
is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
what I saw on the main connector.

On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.cook@sfr.fr wrote:

Le 22 août 2015 à 03:40, Bob Camp kb8tq@n1k.org a écrit :

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the

diagnostic

info you need to go further. Garbled serial is better than none at all.

It suggests

something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even

at

varying baud rates).

You don’t say how you are connecting to the Rb. The manual states:
"RS-232 data is sent to the host on pin 4, received from the host on pin
7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR
or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The transmit
drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These levels are
compatible with
most RS-232 line receivers, but does not require their use (a TTL inverter
may be used
instead), hence simplifies the interface when used inside an instrument at
the sacrifice of
degraded noise immunity over long lines."

So make sure that you adhere to that.

Lamp isn't lit.

What’s the date code. Early versions may be reaching EOL, though 20yrs id
quoted.

Doesn't look great. I'd like to know
if anybody else has wandered down this path. What are common failure

modes?

Anything match up with what I describe? Voltages to check would be

helpful.

The 10MHz out looked okay on a scope. Haven't gone further yet. I

suspect

the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian
Hi, You have too many 1s in your startup string compared to the expected "PRS_10\r". If the MCU clock is not 10Mhz then the integrated UART rates will be off, which should produce framing errors, but do UARTs still detect and systems report these nowadays, or just pass along garbled data? Otherwise, garbled data is most often a result of inadequate pin contact, if the connectors are not seated properly, or the pins or sockets are loose in their shells. Age and rough treatment can have that effect. "Internal hardware jumpers allow these pins to be configured as analog outputs to monitor the lamp intensity and varactor voltage for complete compatibility with the FRS." Have you checked the jumpers in the manual Configuration Notes: "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data. Many system parameters (including the lamp intensity) may be monitored via the RS-232 interface. The function of this pin may be changed to an analog monitor for the lamp intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348) on the microcontroller PCB." On 2015-08-24 22:40, Brian M wrote: > I tried through the weekend, double and triple checking wiring and setup. > I've tried the following methods of getting serial comms working: > PRS10 -> Arduino Uno (with processor bypassed) -> USB Host > PRS10 -> Level Shifter -> BBB UART > PRS10 -> MAX232 -> USB Serial adapter > > Shortly after power is applied to the PRS10, I do get a string of > characters. Believe it should be the model information. Instead I get: > wy+VPgy > > I guess the good news is that this output appears consistent with each > power cycle of the device. And I'm getting the same results through all the > hookup methods I've tried. > > My minicom settings are for software flow control at 9600 8N1 - from what > the manual states, this should be the right settings. I've tried screen as > well - and get the same text. I went crazy trying several other rates and > setting combinations. No luck. > > Maybe I've missed something obvious. > > I agree that getting comms going to the MCU are going to be an important > step. How do people address this type of problem? Scope the serial and try > to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there > further steps people try after that? If nothing else I think there's some > interesting stuff to learn here. I also wouldn't mind tearing out the > electronics, determining if the lamp is good, and attempt to build from > there. I don't know the datecode for the unit, the PCB is marked with a > datecode suggesting 2003? I don't have the full case. I'm trying to assess > what are reasonable next steps. How do I determine if the MCU is healthy? > If the MCU is fried, how do I determine if I just need to squeeze a new MCU > board in there? > > Thanks! I appreciate the input so far! > - Brian > > PS - after looking again at the signal on the scope, it does seem like it > is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like > what I saw on the main connector. > > On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote: > >> >>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : >>> >>> Hi >>> >>> On any microprocessor based gizmo, getting the micro running (again) is >>> generally priority number one. It sets everything up and gives you the >> diagnostic >>> info you need to go further. Garbled serial is better than none at all. >> It suggests >>> something short of a total MCU death spiral … >>> >>> Bob >>> >>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: >>>> >>>> Dear list - >>>> >>>> I have come into possession of a for parts prs 10. I'd like to try to >>>> repair this device. What I've noticed so far. Serial is garbled. (Even >> at >>>> varying baud rates). >> >> You don’t say how you are connecting to the Rb. The manual states: >> "RS-232 data is sent to the host on pin 4, received from the host on pin >> 7. The baud rate is >> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR >> or CTS controls are >> used; rather, the XON/XOFF protocol has been implemented. The transmit >> drive level is 0 >> and 5 V, not the +/-12 V normally associated with RS-232. These levels are >> compatible with >> most RS-232 line receivers, but does not require their use (a TTL inverter >> may be used >> instead), hence simplifies the interface when used inside an instrument at >> the sacrifice of >> degraded noise immunity over long lines." >> >> So make sure that you adhere to that. >> >> >>>> Lamp isn't lit. >> >> What’s the date code. Early versions may be reaching EOL, though 20yrs id >> quoted. >> >>>> Doesn't look great. I'd like to know >>>> if anybody else has wandered down this path. What are common failure >> modes? >>>> Anything match up with what I describe? Voltages to check would be >> helpful. >>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I >> suspect >>>> the crystal is fine. >>>> >>>> Thanks in advance. Happy hacking! >>>> - Brian
BM
Brian M
Tue, Aug 25, 2015 5:35 PM

The earlier suggestion of a missing inverter seems to be the right thing to
chase this evening. I was able to add an inverter and decode the first few
characters on a scope. I get the expected DC1-CR-P-R-S sequence.

Thanks for the input on this. I'll reply back after I've had more time to
hack at this.

  • Brian

On Tuesday, August 25, 2015, Brian Inglis Brian.Inglis@systematicsw.ab.ca
wrote:

Hi,
You have too many 1s in your startup string compared to the expected
"PRS_10\r".
If the MCU clock is not 10Mhz then the integrated UART rates will be off,
which should produce framing errors, but do UARTs still detect and systems
report these nowadays, or just pass along garbled data?
Otherwise, garbled data is most often a result of inadequate pin contact,
if the connectors are not seated properly, or the pins or sockets are loose
in their shells.
Age and rough treatment can have that effect.

"Internal hardware jumpers allow these pins to be configured as analog
outputs
to monitor the lamp intensity and varactor voltage for complete
compatibility
with the FRS."
Have you checked the jumpers in the manual Configuration Notes:
"Pin 4: TXD/PHOTO The default configuration uses this pin as an output for
RS-232 data.
Many system parameters (including the lamp intensity) may be monitored via
the RS-232
interface. The function of this pin may be changed to an analog monitor
for the lamp
intensity by removing one resistor (R347) and installing a 10 kΩ resistor
for another (R348)
on the microcontroller PCB."

On 2015-08-24 22:40, Brian M wrote:

I tried through the weekend, double and triple checking wiring and setup.
I've tried the following methods of getting serial comms working:
PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
PRS10 -> Level Shifter -> BBB UART
PRS10 -> MAX232 -> USB Serial adapter

Shortly after power is applied to the PRS10, I do get a string of
characters. Believe it should be the model information. Instead I get:
wy+VPgy

I guess the good news is that this output appears consistent with each
power cycle of the device. And I'm getting the same results through all
the
hookup methods I've tried.

My minicom settings are for software flow control at 9600 8N1 - from what
the manual states, this should be the right settings. I've tried screen as
well - and get the same text. I went crazy trying several other rates and
setting combinations. No luck.

Maybe I've missed something obvious.

I agree that getting comms going to the MCU are going to be an important
step. How do people address this type of problem? Scope the serial and try
to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
further steps people try after that? If nothing else I think there's some
interesting stuff to learn here. I also wouldn't mind tearing out the
electronics, determining if the lamp is good, and attempt to build from
there. I don't know the datecode for the unit, the PCB is marked with a
datecode suggesting 2003? I don't have the full case. I'm trying to assess
what are reasonable next steps. How do I determine if the MCU is healthy?
If the MCU is fried, how do I determine if I just need to squeeze a new
MCU
board in there?

Thanks! I appreciate the input so far!

  • Brian

PS - after looking again at the signal on the scope, it does seem like it
is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
what I saw on the main connector.

On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.cook@sfr.fr wrote:

Le 22 août 2015 à 03:40, Bob Camp kb8tq@n1k.org a écrit :

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the

diagnostic

info you need to go further. Garbled serial is better than none at all.

It suggests

something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even

at

varying baud rates).

You don’t say how you are connecting to the Rb. The manual states:
"RS-232 data is sent to the host on pin 4, received from the host on pin
7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No
DTR
or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The transmit
drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These levels
are
compatible with
most RS-232 line receivers, but does not require their use (a TTL
inverter
may be used
instead), hence simplifies the interface when used inside an instrument
at
the sacrifice of
degraded noise immunity over long lines."

So make sure that you adhere to that.

Lamp isn't lit.

What’s the date code. Early versions may be reaching EOL, though 20yrs id
quoted.

Doesn't look great. I'd like to know

if anybody else has wandered down this path. What are common failure

modes?

Anything match up with what I describe? Voltages to check would be

helpful.

The 10MHz out looked okay on a scope. Haven't gone further yet. I

suspect

the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence. Thanks for the input on this. I'll reply back after I've had more time to hack at this. - Brian On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote: > Hi, > You have too many 1s in your startup string compared to the expected > "PRS_10\r". > If the MCU clock is not 10Mhz then the integrated UART rates will be off, > which should produce framing errors, but do UARTs still detect and systems > report these nowadays, or just pass along garbled data? > Otherwise, garbled data is most often a result of inadequate pin contact, > if the connectors are not seated properly, or the pins or sockets are loose > in their shells. > Age and rough treatment can have that effect. > > "Internal hardware jumpers allow these pins to be configured as analog > outputs > to monitor the lamp intensity and varactor voltage for complete > compatibility > with the FRS." > Have you checked the jumpers in the manual Configuration Notes: > "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for > RS-232 data. > Many system parameters (including the lamp intensity) may be monitored via > the RS-232 > interface. The function of this pin may be changed to an analog monitor > for the lamp > intensity by removing one resistor (R347) and installing a 10 kΩ resistor > for another (R348) > on the microcontroller PCB." > > On 2015-08-24 22:40, Brian M wrote: > >> I tried through the weekend, double and triple checking wiring and setup. >> I've tried the following methods of getting serial comms working: >> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host >> PRS10 -> Level Shifter -> BBB UART >> PRS10 -> MAX232 -> USB Serial adapter >> >> Shortly after power is applied to the PRS10, I do get a string of >> characters. Believe it should be the model information. Instead I get: >> wy+VPgy >> >> I guess the good news is that this output appears consistent with each >> power cycle of the device. And I'm getting the same results through all >> the >> hookup methods I've tried. >> >> My minicom settings are for software flow control at 9600 8N1 - from what >> the manual states, this should be the right settings. I've tried screen as >> well - and get the same text. I went crazy trying several other rates and >> setting combinations. No luck. >> >> Maybe I've missed something obvious. >> >> I agree that getting comms going to the MCU are going to be an important >> step. How do people address this type of problem? Scope the serial and try >> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there >> further steps people try after that? If nothing else I think there's some >> interesting stuff to learn here. I also wouldn't mind tearing out the >> electronics, determining if the lamp is good, and attempt to build from >> there. I don't know the datecode for the unit, the PCB is marked with a >> datecode suggesting 2003? I don't have the full case. I'm trying to assess >> what are reasonable next steps. How do I determine if the MCU is healthy? >> If the MCU is fried, how do I determine if I just need to squeeze a new >> MCU >> board in there? >> >> Thanks! I appreciate the input so far! >> - Brian >> >> PS - after looking again at the signal on the scope, it does seem like it >> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like >> what I saw on the main connector. >> >> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote: >> >> >>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : >>>> >>>> Hi >>>> >>>> On any microprocessor based gizmo, getting the micro running (again) is >>>> generally priority number one. It sets everything up and gives you the >>>> >>> diagnostic >>> >>>> info you need to go further. Garbled serial is better than none at all. >>>> >>> It suggests >>> >>>> something short of a total MCU death spiral … >>>> >>>> Bob >>>> >>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: >>>>> >>>>> Dear list - >>>>> >>>>> I have come into possession of a for parts prs 10. I'd like to try to >>>>> repair this device. What I've noticed so far. Serial is garbled. (Even >>>>> >>>> at >>> >>>> varying baud rates). >>>>> >>>> >>> You don’t say how you are connecting to the Rb. The manual states: >>> "RS-232 data is sent to the host on pin 4, received from the host on pin >>> 7. The baud rate is >>> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No >>> DTR >>> or CTS controls are >>> used; rather, the XON/XOFF protocol has been implemented. The transmit >>> drive level is 0 >>> and 5 V, not the +/-12 V normally associated with RS-232. These levels >>> are >>> compatible with >>> most RS-232 line receivers, but does not require their use (a TTL >>> inverter >>> may be used >>> instead), hence simplifies the interface when used inside an instrument >>> at >>> the sacrifice of >>> degraded noise immunity over long lines." >>> >>> So make sure that you adhere to that. >>> >>> >>> Lamp isn't lit. >>>>> >>>> >>> What’s the date code. Early versions may be reaching EOL, though 20yrs id >>> quoted. >>> >>> Doesn't look great. I'd like to know >>>>> if anybody else has wandered down this path. What are common failure >>>>> >>>> modes? >>> >>>> Anything match up with what I describe? Voltages to check would be >>>>> >>>> helpful. >>> >>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I >>>>> >>>> suspect >>> >>>> the crystal is fine. >>>>> >>>>> Thanks in advance. Happy hacking! >>>>> - Brian >>>>> >>>> _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >
ZN
ziggy9+time-nuts@pumpkinbrook.com
Tue, Aug 25, 2015 8:38 PM

FYI, if you have an FTDI USB/Serial dongle you can use the FTDI FT-Prog
utility to reprogram the chip to invert polarity from normal. I did that
with my 'Arduino' USB/TTL cable in order to talk to an Rb osc. No need to
mess around with additional inverters. You can get the utility from the
support area of their website.

Paul

On 08/25/2015 01:35 PM, Brian M wrote:

The earlier suggestion of a missing inverter seems to be the right thing to
chase this evening. I was able to add an inverter and decode the first few
characters on a scope. I get the expected DC1-CR-P-R-S sequence.

Thanks for the input on this. I'll reply back after I've had more time to
hack at this.

  • Brian
FYI, if you have an FTDI USB/Serial dongle you can use the FTDI FT-Prog utility to reprogram the chip to invert polarity from normal. I did that with my 'Arduino' USB/TTL cable in order to talk to an Rb osc. No need to mess around with additional inverters. You can get the utility from the support area of their website. Paul On 08/25/2015 01:35 PM, Brian M wrote: > The earlier suggestion of a missing inverter seems to be the right thing to > chase this evening. I was able to add an inverter and decode the first few > characters on a scope. I get the expected DC1-CR-P-R-S sequence. > > Thanks for the input on this. I'll reply back after I've had more time to > hack at this. > > - Brian >
MD
Magnus Danielson
Tue, Aug 25, 2015 9:59 PM

Hang on a minute, polarity does not switch all of a sudden.

However, a short or a glitch could cause the signal to be garbled such
that we incorrectly interpret it as inverted. It can also be the result
of the signal 0 to 5V being triggered on the 0V line on the wrong transient.

It might be that you have a perfectly good signal, but your RS232 can't
interpret it correctly.

So, check the signal, if it has nice digital shape, check if it is only
a matter of RS232 level error. You might need to convert it using a
level shifter. The RS232 trick being used may not be tolerated by all
RS232 inputs.

Cheers,
Magnus

On 08/25/2015 07:35 PM, Brian M wrote:

The earlier suggestion of a missing inverter seems to be the right thing to
chase this evening. I was able to add an inverter and decode the first few
characters on a scope. I get the expected DC1-CR-P-R-S sequence.

Thanks for the input on this. I'll reply back after I've had more time to
hack at this.

  • Brian

On Tuesday, August 25, 2015, Brian Inglis Brian.Inglis@systematicsw.ab.ca
wrote:

Hi,
You have too many 1s in your startup string compared to the expected
"PRS_10\r".
If the MCU clock is not 10Mhz then the integrated UART rates will be off,
which should produce framing errors, but do UARTs still detect and systems
report these nowadays, or just pass along garbled data?
Otherwise, garbled data is most often a result of inadequate pin contact,
if the connectors are not seated properly, or the pins or sockets are loose
in their shells.
Age and rough treatment can have that effect.

"Internal hardware jumpers allow these pins to be configured as analog
outputs
to monitor the lamp intensity and varactor voltage for complete
compatibility
with the FRS."
Have you checked the jumpers in the manual Configuration Notes:
"Pin 4: TXD/PHOTO The default configuration uses this pin as an output for
RS-232 data.
Many system parameters (including the lamp intensity) may be monitored via
the RS-232
interface. The function of this pin may be changed to an analog monitor
for the lamp
intensity by removing one resistor (R347) and installing a 10 kΩ resistor
for another (R348)
on the microcontroller PCB."

On 2015-08-24 22:40, Brian M wrote:

I tried through the weekend, double and triple checking wiring and setup.
I've tried the following methods of getting serial comms working:
PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
PRS10 -> Level Shifter -> BBB UART
PRS10 -> MAX232 -> USB Serial adapter

Shortly after power is applied to the PRS10, I do get a string of
characters. Believe it should be the model information. Instead I get:
wy+VPgy

I guess the good news is that this output appears consistent with each
power cycle of the device. And I'm getting the same results through all
the
hookup methods I've tried.

My minicom settings are for software flow control at 9600 8N1 - from what
the manual states, this should be the right settings. I've tried screen as
well - and get the same text. I went crazy trying several other rates and
setting combinations. No luck.

Maybe I've missed something obvious.

I agree that getting comms going to the MCU are going to be an important
step. How do people address this type of problem? Scope the serial and try
to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
further steps people try after that? If nothing else I think there's some
interesting stuff to learn here. I also wouldn't mind tearing out the
electronics, determining if the lamp is good, and attempt to build from
there. I don't know the datecode for the unit, the PCB is marked with a
datecode suggesting 2003? I don't have the full case. I'm trying to assess
what are reasonable next steps. How do I determine if the MCU is healthy?
If the MCU is fried, how do I determine if I just need to squeeze a new
MCU
board in there?

Thanks! I appreciate the input so far!

  • Brian

PS - after looking again at the signal on the scope, it does seem like it
is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
what I saw on the main connector.

On Sat, Aug 22, 2015 at 2:04 PM Mike Cook michael.cook@sfr.fr wrote:

Le 22 août 2015 à 03:40, Bob Camp kb8tq@n1k.org a écrit :

Hi

On any microprocessor based gizmo, getting the micro running (again) is
generally priority number one. It sets everything up and gives you the

diagnostic

info you need to go further. Garbled serial is better than none at all.

It suggests

something short of a total MCU death spiral …

Bob

On Aug 21, 2015, at 7:26 PM, Brian M brayniac@gmail.com wrote:

Dear list -

I have come into possession of a for parts prs 10. I'd like to try to
repair this device. What I've noticed so far. Serial is garbled. (Even

at

varying baud rates).

You don’t say how you are connecting to the Rb. The manual states:

"RS-232 data is sent to the host on pin 4, received from the host on pin
7. The baud rate is
fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No
DTR
or CTS controls are
used; rather, the XON/XOFF protocol has been implemented. The transmit
drive level is 0
and 5 V, not the +/-12 V normally associated with RS-232. These levels
are
compatible with
most RS-232 line receivers, but does not require their use (a TTL
inverter
may be used
instead), hence simplifies the interface when used inside an instrument
at
the sacrifice of
degraded noise immunity over long lines."

So make sure that you adhere to that.

Lamp isn't lit.

What’s the date code. Early versions may be reaching EOL, though 20yrs id
quoted.

Doesn't look great. I'd like to know

if anybody else has wandered down this path. What are common failure

modes?

Anything match up with what I describe? Voltages to check would be

helpful.

The 10MHz out looked okay on a scope. Haven't gone further yet. I

suspect

the crystal is fine.

Thanks in advance. Happy hacking!

  • Brian

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.


time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hang on a minute, polarity does not switch all of a sudden. However, a short or a glitch could cause the signal to be garbled such that we incorrectly interpret it as inverted. It can also be the result of the signal 0 to 5V being triggered on the 0V line on the wrong transient. It might be that you have a perfectly good signal, but your RS232 can't interpret it correctly. So, check the signal, if it has nice digital shape, check if it is only a matter of RS232 level error. You might need to convert it using a level shifter. The RS232 trick being used may not be tolerated by all RS232 inputs. Cheers, Magnus On 08/25/2015 07:35 PM, Brian M wrote: > The earlier suggestion of a missing inverter seems to be the right thing to > chase this evening. I was able to add an inverter and decode the first few > characters on a scope. I get the expected DC1-CR-P-R-S sequence. > > Thanks for the input on this. I'll reply back after I've had more time to > hack at this. > > - Brian > > On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> > wrote: > >> Hi, >> You have too many 1s in your startup string compared to the expected >> "PRS_10\r". >> If the MCU clock is not 10Mhz then the integrated UART rates will be off, >> which should produce framing errors, but do UARTs still detect and systems >> report these nowadays, or just pass along garbled data? >> Otherwise, garbled data is most often a result of inadequate pin contact, >> if the connectors are not seated properly, or the pins or sockets are loose >> in their shells. >> Age and rough treatment can have that effect. >> >> "Internal hardware jumpers allow these pins to be configured as analog >> outputs >> to monitor the lamp intensity and varactor voltage for complete >> compatibility >> with the FRS." >> Have you checked the jumpers in the manual Configuration Notes: >> "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for >> RS-232 data. >> Many system parameters (including the lamp intensity) may be monitored via >> the RS-232 >> interface. The function of this pin may be changed to an analog monitor >> for the lamp >> intensity by removing one resistor (R347) and installing a 10 kΩ resistor >> for another (R348) >> on the microcontroller PCB." >> >> On 2015-08-24 22:40, Brian M wrote: >> >>> I tried through the weekend, double and triple checking wiring and setup. >>> I've tried the following methods of getting serial comms working: >>> PRS10 -> Arduino Uno (with processor bypassed) -> USB Host >>> PRS10 -> Level Shifter -> BBB UART >>> PRS10 -> MAX232 -> USB Serial adapter >>> >>> Shortly after power is applied to the PRS10, I do get a string of >>> characters. Believe it should be the model information. Instead I get: >>> wy+VPgy >>> >>> I guess the good news is that this output appears consistent with each >>> power cycle of the device. And I'm getting the same results through all >>> the >>> hookup methods I've tried. >>> >>> My minicom settings are for software flow control at 9600 8N1 - from what >>> the manual states, this should be the right settings. I've tried screen as >>> well - and get the same text. I went crazy trying several other rates and >>> setting combinations. No luck. >>> >>> Maybe I've missed something obvious. >>> >>> I agree that getting comms going to the MCU are going to be an important >>> step. How do people address this type of problem? Scope the serial and try >>> to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there >>> further steps people try after that? If nothing else I think there's some >>> interesting stuff to learn here. I also wouldn't mind tearing out the >>> electronics, determining if the lamp is good, and attempt to build from >>> there. I don't know the datecode for the unit, the PCB is marked with a >>> datecode suggesting 2003? I don't have the full case. I'm trying to assess >>> what are reasonable next steps. How do I determine if the MCU is healthy? >>> If the MCU is fried, how do I determine if I just need to squeeze a new >>> MCU >>> board in there? >>> >>> Thanks! I appreciate the input so far! >>> - Brian >>> >>> PS - after looking again at the signal on the scope, it does seem like it >>> is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like >>> what I saw on the main connector. >>> >>> On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote: >>> >>> >>>> Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : >>>>> >>>>> Hi >>>>> >>>>> On any microprocessor based gizmo, getting the micro running (again) is >>>>> generally priority number one. It sets everything up and gives you the >>>>> >>>> diagnostic >>>> >>>>> info you need to go further. Garbled serial is better than none at all. >>>>> >>>> It suggests >>>> >>>>> something short of a total MCU death spiral … >>>>> >>>>> Bob >>>>> >>>>> On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: >>>>>> >>>>>> Dear list - >>>>>> >>>>>> I have come into possession of a for parts prs 10. I'd like to try to >>>>>> repair this device. What I've noticed so far. Serial is garbled. (Even >>>>>> >>>>> at >>>> >>>>> varying baud rates). >>>>>> >>>>> >>>> You don’t say how you are connecting to the Rb. The manual states: >>>> "RS-232 data is sent to the host on pin 4, received from the host on pin >>>> 7. The baud rate is >>>> fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No >>>> DTR >>>> or CTS controls are >>>> used; rather, the XON/XOFF protocol has been implemented. The transmit >>>> drive level is 0 >>>> and 5 V, not the +/-12 V normally associated with RS-232. These levels >>>> are >>>> compatible with >>>> most RS-232 line receivers, but does not require their use (a TTL >>>> inverter >>>> may be used >>>> instead), hence simplifies the interface when used inside an instrument >>>> at >>>> the sacrifice of >>>> degraded noise immunity over long lines." >>>> >>>> So make sure that you adhere to that. >>>> >>>> >>>> Lamp isn't lit. >>>>>> >>>>> >>>> What’s the date code. Early versions may be reaching EOL, though 20yrs id >>>> quoted. >>>> >>>> Doesn't look great. I'd like to know >>>>>> if anybody else has wandered down this path. What are common failure >>>>>> >>>>> modes? >>>> >>>>> Anything match up with what I describe? Voltages to check would be >>>>>> >>>>> helpful. >>>> >>>>> The 10MHz out looked okay on a scope. Haven't gone further yet. I >>>>>> >>>>> suspect >>>> >>>>> the crystal is fine. >>>>>> >>>>>> Thanks in advance. Happy hacking! >>>>>> - Brian >>>>>> >>>>> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >
BI
Brian Inglis
Wed, Aug 26, 2015 12:02 AM

Looking at the data expected and received on the wire, there could be an extra inversion after some bits delay until an inverted 1 is detected as a start bit:
00001101 00110000 00110001 01011111 01010011 01010010 01010000  .01_SRP - what you should see on your scope
01111001 01100111 01010000 01010110 00101011 01111001 01110111  ygPV+yw - what you probably see on your scope

You should be able to connect your output data directly into any
current PC serial port as they should both work with 0-5V nowadays.

On 2015-08-25 11:35, Brian M wrote:

The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence.

Thanks for the input on this. I'll reply back after I've had more time to hack at this.

On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis@systematicsw.ab.ca mailto:Brian.Inglis@systematicsw.ab.ca> wrote:

 You have too many 1s in your startup string compared to the expected "PRS_10\r".
 If the MCU clock is not 10Mhz then the integrated UART rates will be off,
 which should produce framing errors, but do UARTs still detect and systems
 report these nowadays, or just pass along garbled data?
 Otherwise, garbled data is most often a result of inadequate pin contact,
 if the connectors are not seated properly, or the pins or sockets are loose
 in their shells.
 Age and rough treatment can have that effect.

 "Internal hardware jumpers allow these pins to be configured as analog outputs
 to monitor the lamp intensity and varactor voltage for complete compatibility
 with the FRS."
 Have you checked the jumpers in the manual Configuration Notes:
 "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data.
 Many system parameters (including the lamp intensity) may be monitored via the RS-232
 interface. The function of this pin may be changed to an analog monitor for the lamp
 intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348)
 on the microcontroller PCB."
 On 2015-08-24 22:40, Brian M wrote:
     I tried through the weekend, double and triple checking wiring and setup.
     I've tried the following methods of getting serial comms working:
     PRS10 -> Arduino Uno (with processor bypassed) -> USB Host
     PRS10 -> Level Shifter -> BBB UART
     PRS10 -> MAX232 -> USB Serial adapter

     Shortly after power is applied to the PRS10, I do get a string of
     characters. Believe it should be the model information. Instead I get:
     wy+VPgy

     I guess the good news is that this output appears consistent with each
     power cycle of the device. And I'm getting the same results through all the
     hookup methods I've tried.

     My minicom settings are for software flow control at 9600 8N1 - from what
     the manual states, this should be the right settings. I've tried screen as
     well - and get the same text. I went crazy trying several other rates and
     setting combinations. No luck.

     Maybe I've missed something obvious.

     I agree that getting comms going to the MCU are going to be an important
     step. How do people address this type of problem? Scope the serial and try
     to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there
     further steps people try after that? If nothing else I think there's some
     interesting stuff to learn here. I also wouldn't mind tearing out the
     electronics, determining if the lamp is good, and attempt to build from
     there. I don't know the datecode for the unit, the PCB is marked with a
     datecode suggesting 2003? I don't have the full case. I'm trying to assess
     what are reasonable next steps. How do I determine if the MCU is healthy?
     If the MCU is fried, how do I determine if I just need to squeeze a new MCU
     board in there?

     Thanks! I appreciate the input so far!
     - Brian

     PS - after looking again at the signal on the scope, it does seem like it
     is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like
     what I saw on the main connector.

     On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote:


             Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit :

             Hi

             On any microprocessor based gizmo, getting the micro running (again) is
             generally priority number one. It sets everything up and gives you the

         diagnostic

             info you need to go further. Garbled serial is better than none at all.

         It suggests

             something short of a total MCU death spiral …

             Bob

                 On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote:

                 Dear list -

                 I have come into possession of a for parts prs 10. I'd like to try to
                 repair this device. What I've noticed so far. Serial is garbled. (Even

         at

                 varying baud rates).


            You don’t say how you are connecting to the Rb. The manual states:
         "RS-232 data is sent to the host on pin 4, received from the host on pin
         7. The baud rate is
         fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR
         or CTS controls are
         used; rather, the XON/XOFF protocol has been implemented. The transmit
         drive level is 0
         and 5 V, not the +/-12 V normally associated with RS-232. These levels are
         compatible with
         most RS-232 line receivers, but does not require their use (a TTL inverter
         may be used
         instead), hence simplifies the interface when used inside an instrument at
         the sacrifice of
         degraded noise immunity over long lines."

         So make sure that you adhere to that.


                 Lamp isn't lit.


         What’s the date code. Early versions may be reaching EOL, though 20yrs id
         quoted.

                 Doesn't look great. I'd like to know
                 if anybody else has wandered down this path. What are common failure

         modes?

                 Anything match up with what I describe? Voltages to check would be

         helpful.

                 The 10MHz out looked okay on a scope. Haven't gone further yet. I

         suspect

                 the crystal is fine.

                 Thanks in advance. Happy hacking!
Looking at the data expected and received on the wire, there could be an extra inversion after some bits delay until an inverted 1 is detected as a start bit: 00001101 00110000 00110001 01011111 01010011 01010010 01010000 .01_SRP - what you should see on your scope 01111001 01100111 01010000 01010110 00101011 01111001 01110111 ygPV+yw - what you probably see on your scope You should be able to connect your output data directly into any current PC serial port as they should both work with 0-5V nowadays. On 2015-08-25 11:35, Brian M wrote: > The earlier suggestion of a missing inverter seems to be the right thing to chase this evening. I was able to add an inverter and decode the first few characters on a scope. I get the expected DC1-CR-P-R-S sequence. > > Thanks for the input on this. I'll reply back after I've had more time to hack at this. > On Tuesday, August 25, 2015, Brian Inglis <Brian.Inglis@systematicsw.ab.ca <mailto:Brian.Inglis@systematicsw.ab.ca>> wrote: > You have too many 1s in your startup string compared to the expected "PRS_10\r". > If the MCU clock is not 10Mhz then the integrated UART rates will be off, > which should produce framing errors, but do UARTs still detect and systems > report these nowadays, or just pass along garbled data? > Otherwise, garbled data is most often a result of inadequate pin contact, > if the connectors are not seated properly, or the pins or sockets are loose > in their shells. > Age and rough treatment can have that effect. > > "Internal hardware jumpers allow these pins to be configured as analog outputs > to monitor the lamp intensity and varactor voltage for complete compatibility > with the FRS." > Have you checked the jumpers in the manual Configuration Notes: > "Pin 4: TXD/PHOTO The default configuration uses this pin as an output for RS-232 data. > Many system parameters (including the lamp intensity) may be monitored via the RS-232 > interface. The function of this pin may be changed to an analog monitor for the lamp > intensity by removing one resistor (R347) and installing a 10 kΩ resistor for another (R348) > on the microcontroller PCB." > On 2015-08-24 22:40, Brian M wrote: > I tried through the weekend, double and triple checking wiring and setup. > I've tried the following methods of getting serial comms working: > PRS10 -> Arduino Uno (with processor bypassed) -> USB Host > PRS10 -> Level Shifter -> BBB UART > PRS10 -> MAX232 -> USB Serial adapter > > Shortly after power is applied to the PRS10, I do get a string of > characters. Believe it should be the model information. Instead I get: > wy+VPgy > > I guess the good news is that this output appears consistent with each > power cycle of the device. And I'm getting the same results through all the > hookup methods I've tried. > > My minicom settings are for software flow control at 9600 8N1 - from what > the manual states, this should be the right settings. I've tried screen as > well - and get the same text. I went crazy trying several other rates and > setting combinations. No luck. > > Maybe I've missed something obvious. > > I agree that getting comms going to the MCU are going to be an important > step. How do people address this type of problem? Scope the serial and try > to decode by hand? The 10Mhz to the MCU looks OK on a scope. Are there > further steps people try after that? If nothing else I think there's some > interesting stuff to learn here. I also wouldn't mind tearing out the > electronics, determining if the lamp is good, and attempt to build from > there. I don't know the datecode for the unit, the PCB is marked with a > datecode suggesting 2003? I don't have the full case. I'm trying to assess > what are reasonable next steps. How do I determine if the MCU is healthy? > If the MCU is fried, how do I determine if I just need to squeeze a new MCU > board in there? > > Thanks! I appreciate the input so far! > - Brian > > PS - after looking again at the signal on the scope, it does seem like it > is 9600 baud. ~100µS per bit. The data out on the MCU itself looks like > what I saw on the main connector. > > On Sat, Aug 22, 2015 at 2:04 PM Mike Cook <michael.cook@sfr.fr> wrote: > > > Le 22 août 2015 à 03:40, Bob Camp <kb8tq@n1k.org> a écrit : > > Hi > > On any microprocessor based gizmo, getting the micro running (again) is > generally priority number one. It sets everything up and gives you the > > diagnostic > > info you need to go further. Garbled serial is better than none at all. > > It suggests > > something short of a total MCU death spiral … > > Bob > > On Aug 21, 2015, at 7:26 PM, Brian M <brayniac@gmail.com> wrote: > > Dear list - > > I have come into possession of a for parts prs 10. I'd like to try to > repair this device. What I've noticed so far. Serial is garbled. (Even > > at > > varying baud rates). > > > You don’t say how you are connecting to the Rb. The manual states: > "RS-232 data is sent to the host on pin 4, received from the host on pin > 7. The baud rate is > fixed at 9600 baud, 8 bits, no parity, with 1 start and 1 stop bit. No DTR > or CTS controls are > used; rather, the XON/XOFF protocol has been implemented. The transmit > drive level is 0 > and 5 V, not the +/-12 V normally associated with RS-232. These levels are > compatible with > most RS-232 line receivers, but does not require their use (a TTL inverter > may be used > instead), hence simplifies the interface when used inside an instrument at > the sacrifice of > degraded noise immunity over long lines." > > So make sure that you adhere to that. > > > Lamp isn't lit. > > > What’s the date code. Early versions may be reaching EOL, though 20yrs id > quoted. > > Doesn't look great. I'd like to know > if anybody else has wandered down this path. What are common failure > > modes? > > Anything match up with what I describe? Voltages to check would be > > helpful. > > The 10MHz out looked okay on a scope. Haven't gone further yet. I > > suspect > > the crystal is fine. > > Thanks in advance. Happy hacking!