OK, it wasn't clear from your drawing but it looks like you have the RS-485 ground reference covered.
One thing to check is the power supply. Just how much current can you get from the 12V supply?
Decoupling caps on the RS-485 driver would help with edge speeds and probably not much else. At your low bit rate it wouldn't be at the top of my list.
I can't say much about the Teensy drivers. I am more a go it alone type. When I run into trouble it is at a much lower level. My last dive into RS-485 resulted in TI issuing an errata on the USART.
Looking back I see that the line idles with a "0" state. This could cause trouble when you switch from transmit to receive. While in transmit mode the receiver is disabled and the Teensy should see a "1". Then when you switch off the transmitter it is enabled and that idle line state of "0" comes through. A start bit. The receiver dutifully runs through its paces but when it comes time for the stop bits, it sees "0". Framing error.
Idle state biasing would seem to be in order so long as the existing hardware is happy with an idle state of "1".
Thanks again for sharing your knowledge and providing guiding questions.
I'm not sure how much current the 12V supply can provide but it is protected by a 3AMP fuse on the main board. The 4-wires run to each of a maximum of 8 thermostats are no more than 50-75 feet long in any normal home. This is pretty short for RS485 I believe but I haven't measured the resistance in the wires.
I'm not used to Arduino. I'm more used to building up from raw hardware with or without RTOS and doing the drivers myself -- like you -- and in those cases I learn bottoms up instead of top down like with Arduino where you skip the BSP development and have no JTAG debugger AND you get to skip reading thousands of pages of register programming model. But when you face a problem like this - debugging (for me) is more difficult without all of that 'tedious' pre-work. So I'm doing my learning (and stumbling) in public here. No shame in learning is there?
Since you bring up the possible issue with the idle state of the RX being at zero volts and this was mentioned by rcarr in #9 in this thread, I want to discuss the idle state a bit.
For more context, here is a schematic of the Old Thermostat which I'm trying to replace with an electrically and functionally compatible design so I can remove the old thermostats and install the new ones with better UI in their place but do not have to replace the central controller (which would require another completely different design too). This desire (and my ignorance of real hardware design) is why I used the same
MAX483CPA transceiver and the same (10K) termination resistance. I just hoped copying it would work and all I needed to do was firmware! If wishes had horses beggars would ride, eh? Anyway, here's the 15 year old schematic.
I circled the part of the circuitry (in red) that I copied in my (currently) breadboard based prototype. The MCU used is a
PIC16F876A. The design uses through-hole PCA. In this design there is no pull-up resistor on either the Rx or Tx line. But there are bypass capacitors on the 5V output from the voltage regulator that converts 12V to 5V for the design. I didn't know about those until recently so my prototype breadboard based design does not yet have them. There are no failsafe resistors in the network. All rs485 thermostat nodes have a 10K termination resistor about .5" from the terminal block. The central controller does NOT have termination resistor. I don't know why. My house is connected in a 'star' topology with the central controller in the center. I'm told by the inventor of this system (who hired a contractor in 2002 to convert his mercury switch based analog design he'd sold for years into the digital one) that some homes are connected in a daisy chain. The communication works reliably except for the software protocol used for half-duplex communication which sometimes glitches and takes multiple 10s of seconds or longer to stabilize into normal reliable steady state operation. My new design doesn't need to improve on the communication but should work at least as good.
In this older PIC design, the RX line idles low. The TX line however idles high.
I disconnected my prototype from the home network and collected these scope traces this morning.
One thing I noticed right away about the transmit trace: The transceiver signal drops to zero between bytes in
most but not all frames. In the Teensy design using the Serial1.transmitEnable() for pin control, the signal stays high for all 8 bytes of the frame. Here are 5 images:
Receiver Idle trace (channel 2, ignore channel 1 signal. I forgot to turn off the channel 1 waveform)
Receiver 1 frame trace (channel 2)
Transmitter Idle Trace (channel 2 is TX, channel 1 is transceiver control)
Transmitter frame trace
Transmitter 'glitch' frame trace -- where we don't see the transceiver direction control drop to zero between each transmitted byte.
So with two experts (you and rcarr) concerned about the low idle state and the original designer of this legacy system unavailable for consultation, I'm concerned as well and want to know more about basic USART serial IO so I'm going to be doing some reading today before I change any hardware or firmware in my prototype. I noticed that the Kinetis UART provides separate polarity control for both signals and I was wondering if I needed to do something with that feature for compatibility with this PIC based system. During my work with the scope I found that the trace of an 8 byte frame was captured
much better if I used low-to-high edge triggering on the RX signal but used high-to-low edge triggering on the TX signal.
One other observation I made of the home system running (without my prototype connected) but didn't photograph: The A and B signals coming into the thermostat are voltage-shifted high. At rest A is about 1.0V and B is about 1.3V. The amplitude of the A signal is higher than that of B. A reaches about 4.5V and B reaches 3V. This voltage differential does not
seem to harm the reception or transmission of bytes over the RS485 between nodes but I have no actual data from inside the devices to confirm this hypothesis. I just have been using the system for 14 years and it has been working. Biggest glitches occur following a power outage. Sometimes I have to manually reboot the system using the breaker box.