I see that this product has been discontinued.
Are there plans to create an updated replacement for this board?
Would the replacement be designed for the PI B+? Would it use a different chip? When might a replacement be available?

Am I reading something wrong? I googled the FET on the schematic for the Tx and Rx LEDs, and it seems to be a p-channel FET: NTR1P02T1G. It looks, on the schematic, like a place you'd use an n-channel (low side switching).

This design may use a 485 transceiver and serve for some use (?), but it is NOT an RS-485 at all. The part should be connected to drive transmit data differentially both ways, 1 and 0.

I have often used this configuration. What really happens is that the device is only capable of transmitting zeros, because when you transmit ones, you're actually disabling the output driver so it stays in tri-state over the duration high-level bits. This can only be possible considering the idle status of the bus is at a high level and some other device on the bus is responsible for maintaining that state, otherwise it is necessary to ensure the high state adding biasing resistors at the end of bus. In fact, pin 4 on MAX481 could be grounded with no effects on data communication (obviously disconnecting it from TXD).

The MAX481 datasheet says maximum data rate is 2.5MBPS not 10MBPS. Both Donn and Alberto are correct. I cannot see how you can control the Driver enable and receiver enable using the TXD signal. When a byte is transmitted some bits will be zero and the Driver enable will be off and the driver output will be in tristate.

To get 10MBPS over 4000feet using RS485 is fanciful. There are no termination resistors to handle ringing and reflections. I have experienced situations in industry where I needed a RS482 repeater to transfer data over 1Km at 9600BPS.

Sorry to be pedantic, but RS485 is NOT a protocol, it is an electrical spec for a multidrop capable differential communication interface, which the MAX481 implements. Any number of protocols can and are run over RS485 - master/slave, TDMA, CSMACD, ... LinkSprite may have a protocol they like to run over this, but I haven't looked. Achieving those performance numbers requires great care w/ termination and cabling - reflections are not your friend. Thanks.

I'm trying to understand how it can work.

TXD toggle both enables (~RE and DE) and same time it used as TXD!. You can't use TXD as enable because DE (transmitter enable) must be tied low in order to receive. If you enable your own transmitter you force A/B lines to whatever TXD put on the transmitter buffer (and you are enabling DE with TXD eventually on a frame output, but just when TXD its low -DE high, ~RE high-)

I think this uses the driver delays in order to work -best guess-, with TXD high -DE low, ~RE low- A/B outputs are H-Z. TXD low -DE high, ~RE high- A/B outputs are tied to TXD state (DI = 0) with A=1/B=0. If you put TXD high again, there is a delay from the enable that allow you to put A=0/B=1 until the internal parts put both on H-Z but this is bad idea, you're cutting the output level to whatever enable time is -mostly random and varies from part to part for sure-.

And, by the way (this can be solved with software but this is an bad idea), you need the RXD (and ~RE) enabled along the TXD frame or plain-text: you need to see your echo. This is because the low level -maybe high, sorry the dyslexia- is dominant this is how you control the collisions on the bus. If you put a high level and you are seeing a low level there is something messing with your bus and you need to stop and listen. Toggle the enables with TXD, and you dont know what are you doing, you transmitt blindy and happy but other devices on the bus will be very angry.

So, what am I missing ?

why does linksprite insist on using half duplex? all of their shields are half duplex...