[time-nuts] SRS PRS10 repair

Wed Aug 26 00:02:42 UTC 2015

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 at systematicsw.ab.ca <mailto:Brian.Inglis at 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 at sfr.fr> wrote:
>
>
>                 Le 22 août 2015 à 03:40, Bob Camp <kb8tq at 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 at 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!