[time-nuts] SRS PRS10 repair
Brian.Inglis at SystematicSw.ab.ca
Tue Aug 25 20:02:42 EDT 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:
> 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 :
> On any microprocessor based gizmo, getting the micro running (again) is
> generally priority number one. It sets everything up and gives you the
> info you need to go further. Garbled serial is better than none at all.
> It suggests
> something short of a total MCU death spiral …
> 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
> 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
> Doesn't look great. I'd like to know
> if anybody else has wandered down this path. What are common failure
> Anything match up with what I describe? Voltages to check would be
> The 10MHz out looked okay on a scope. Haven't gone further yet. I
> the crystal is fine.
> Thanks in advance. Happy hacking!
More information about the time-nuts