Maximum serial baudrate for full-duplex application

[bask185]

Hello,

Recently I came into contact with EtherCat, and it made me think of something.

I want to make something similar for arduino using max485 modules (they cost 50 cents nowadays). The idea is that the Tx of the master arduino goes to the Rx of the next arduino via rs485 and this goes on and on (daisy chaining in a circle). I want to use an 8 pole flat-cable with clickable connectors (because is cheap) 2 lines are for RS 485 buses, 2 for ground and 2 for 5V lines.

I first want to start out by letting the slave arduino's act purely as IO extenders which are controlled by the master. The master sends 1 byte to initiate transmission. The ammount of bytes the master will send in a single transmission is related to the ammount of slaves. This first byte will have the value 0. Further there are 2 bytes reserved per arduino with information for and from the GPIO pins.

When the first slave reads in the 0, it knows that the following 2 bytes (bytes 1 and 2) are reserved for that particular slave. The slave will increment this 0 to 1 and immediately relays it to the next arduino. The next arduino which gets the '1' knows that bytes 3 and 4 are reserved for him. Than this arduino increments the 1 to 2 and relays it to the 3rd arduino etc etc. Finally the last arduino receives his number, increments it, and relays it to the next.

However there is no next device. Instead: The outgoing connector of the last slave will be wired so that the first rs485 is wired to the 2nd rs485 bus which will lead all the way back to the master's Rx pin. The master than receives the first byte of a packet which he is still transmitting at that moment. The received number must match with the configured ammount of slaves. If the number differs, the master knows that atleast 1 slave is malfunctioning or missing.

Received bytes are to be read and/or modified and retransmitted to the next device ASAP. Every slave has the ability to modify the received bytes before retransmitting them. The arduino can put information of it's inputs in the byte and then relays the byte to the following device untill the modified byte reaches the master.

The bytes can also already contain information regarding the output pins. The very first transmission will also initialize all IO of all slave modules. Therefor any slave's ID is depended off his position in the bus.

Summarized:
In the beginning of a transmission, a slave will receive a number, this number tells him which of the following bytes of the transmission are ment for him. These bytes may contain information for his output pins and he must OR the bits with the states of his inputs. The transmission will be fed into a 2nd rs485 bus back to the master.

The reason why I want to this, is because I use rs485 alot for my model track but I have no implemented methods for collision avoiding or collision detection. My theory was that the chances for this to happen were so incredibly small, it would not occur. This theory still stands today. Ofcourse I would like something betters. And letting the master device poll information per slave (like is done with modbus) does not have me preference.

Now the questions.

I'd like to have this running as fast as possible. I've read that the maximum baudrate of 2M for an atmega328P can be realized. However every device needs to be able to receive and transmit simultaneously. So I believe this might influence the performance too negatively?

What would the highest achiefable baudrate transceive full duplex?

Also. I've not yet looked into the hardware serial library of arduino. I've heared that not everybody thinks it is very efficient. For work I programmed an 8051 chip and a made 2 circular buffers for serial communication. So I did not had to wait while(transmitt_flag || receive_flag) all the time. Does the arduino library wait while for the transmit and receive flags or is it efficient enough?

Lastly?
Out of curiosity what do you think of my method for communicating between arduinos?

general schematic:

[Paul_KD7HB]

Start small and test often. Do you have the proper test equipment for your communications?

Paul

[pylon]

The idea is that the Tx of the master arduino goes to the Rx of the next arduino via rs485 and this goes on and on (daisy chaining in a circle).

You know that an RS-485 bus is multi-device capable, don't you?

I first want to start out by letting the slave arduino's act purely as IO extenders which are controlled by the master. The master sends 1 byte to initiate transmission. The ammount of bytes the master will send in a single transmission is related to the ammount of slaves. This first byte will have the value 0. Further there are 2 bytes reserved per arduino with information for and from the GPIO pins.

When the first slave reads in the 0, it knows that the following 2 bytes (bytes 1 and 2) are reserved for that particular slave. The slave will increment this 0 to 1 and immediately relays it to the next arduino. The next arduino which gets the '1' knows that bytes 3 and 4 are reserved for him. Than this arduino increments the 1 to 2 and relays it to the 3rd arduino etc etc. Finally the last arduino receives his number, increments it, and relays it to the next.

This is overly complex and I cannot see an advantage over a simple full-duplex RS-485 bus where all devices are connected directly.

If the number differs, the master knows that atleast 1 slave is malfunctioning or missing.

Does that help? Does it have a way to recover?

I'd like to have this running as fast as possible. I've read that the maximum baudrate of 2M for an atmega328P can be realized.

I doubt that. If the ATmega328 receives data at 2Mbps it won't be able to handle that data and transfer it at the same speed without a substantial delay. It won't be able to buffer that data in larger networks as the RAM is very limited (2kB).

What would the highest achiefable baudrate transceive full duplex?

That depends largely on the complexity of the protocol. If I got your description correctly, this involves not only repeating the information but mangling it before. So in reality the maximum speed you probably might reach is between 100kbps and 250kbps, I'd guess.

Does the arduino library wait while for the transmit and receive flags or is it efficient enough?

I don't know what "wait" means but the hardware serial library is implemented quite efficiently (I guess you confused with the SoftwareSerial library), it uses buffers and does the actual hardware loading in interrupt handlers.

[bask185]

Paul_KD7HB:
Do you have the proper test equipment for your communications?

Not really (analog scope here). I have an arduino mega with extra serial ports. So I can write a program which would output all slave inputs on the monitor. And I can echo inputs of the slave to any of the mega's Io pins

pylon:
You know that an RS-485 bus is multi-device capable, don't you?

Yes ofcourse I know that, I also know that a single bus is only half duplex. You need atleast 4 wires. That means 2 max485 ICs per slave device.

pylon:
This is overly complex and I cannot see an advantage over a simple full-duplex RS-485 bus where all devices are connected directly.

Are you seriously? EtherCat which is like the best industrial fieldbus currently in existance does it precisely like this. Only they use ethernet connections and their IO devices handle 1 bit per time. Yet this bus is so incredibly fast that is considered real time.

Imagine if you have 5 slaves with each 16 IO. If you want to request 16 IO states, you need to send atleast 1 byte depending on how you deal with addresses, than you need to wait for a 2 byte respons. Or if you want to update outputs you need to send atleast 3 bytes. So that is 3 bytes transmission per slave. + every slave needs an address. Now this can be realized with just 1 bus.

If you want 2 buses for a full duplex communication, you'd propably have your slaves send input updates automatically. But then you risk transmission collisions. So you either need to do something with an embedded clockline and time sharing. Or do something with an acknowledge system or implement a CDC check.

But we are not there yet. If you want to poll slaves to handle both outputs as well as inputs. You'd have to send ID + 2 bytes for outputs and then wait for 2 bytes for input states so a total transmission would be 5 bytes per slave. So for 5 slaves that would be a total transmission of 25 bytes to exhange all IO information with just 1 bus.

With my method it is just 2 bytes per slave + 1. Which will be 11 bytes. + I do not need separate ID's. So no unique software versions, no eeprom usage to store an ID, no hardware address pins. I can easily change out slaves without problems. Regardless of how you would use your max485 modules, this method will always be faster.

I don't know what "wait" means but the hardware serial library is implemented quite efficiently (I guess you confused with the SoftwareSerial library)
[/quote]
This is almost insulting. I am not confused of anything. First of all I did not know how arduino handled the hardware serial library precicsely. That is why I was asking about this. I do know that they used buffers and interrupts. But there is more than 1 way to handle interrupts.

I have seen software for 8051 uController in which the code would wait on the transmit/receive flags to be cleared. In this code you'd find these lines:

sbuf = someByte;
while(TI); wait untill sbuf is clocked out

When I was a student I did precisely this when I wrote an I2C library for a PIC.

This I was trying to explain with

transmitt_flag || receive_flag)

Does that help? Does it have a way to recover?

Ofcourse it helps to know if a slave is not functioning properly, why would this not be helpful? And I can think of ways of recovering. I reserve 6 bits for adrresses I can embed 2 control bits, with which I could implement a reconnection attempt or something.

[Railroader]

What You describle looks like a "Round Robin protocool" invented 50 years ago. Give it some time and search for information about it! Every node needs to receive and transmit every message and it costs CPU power that will affect the remaining CPU power left for other tasks witin the nodes. I once had the same ideas but never launched them.

[MorganS]

Your initial description sounds like what WS2812 addressable LEDs do. But backwards. That starts with the number of LEDs and counts down to zero.

If the master wants to read a byte from a slave then it must send an empty byte addressed to that slave for it to modify? That sounds like SPI except with a lot more overhead.

The maximum speed and length depends on the characteristics of the transmission line. I suggest you read up on impedance matching theory.

"As fast as possible" is not a specification. How fast do you need? Select a technology which can go that fast. Modern plant control networks use Ethernet because the hardware is cheap and some of the devices like machine-vision cameras are sending megabits per second of data.

[pylon]

I also know that a single bus is only half duplex.

Wrong, you can have the bus full-duplex.

You need atleast 4 wires. That means 2 max485 ICs per slave device.

Same as your concept needs. But for a full-duplex bus I would use MAX490/491 anyway, for both concepts.

Are you seriously? EtherCat which is like the best industrial fieldbus currently in existance does it precisely like this. Only they use ethernet connections and their IO devices handle 1 bit per time. Yet this bus is so incredibly fast that is considered real time.

There is no best bus for all usages so you might find it a very good fieldbus but as you don't use it but try to emulate it on a different physical layer shows us that their might be limitation of your "best fieldbus".

The general concept may be useful in some situations, I see a lot of drawbacks in others.

Imagine if you have 5 slaves with each 16 IO. If you want to request 16 IO states, you need to send atleast 1 byte depending on how you deal with addresses, than you need to wait for a 2 byte respons. Or if you want to update outputs you need to send atleast 3 bytes. So that is 3 bytes transmission per slave. + every slave needs an address. Now this can be realized with just 1 bus.

That's a situation where slaves only have IOs. What if you have temperature sensors, keyboard or any other a bit more complex device on the bus? Sure you can handle that with a bit based protocol but it's often a waste of resources.

If you want 2 buses for a full duplex communication, you'd propably have your slaves send input updates automatically.

Not necessarily. The values may be explicitly requested by the master.

But we are not there yet. If you want to poll slaves to handle both outputs as well as inputs. You'd have to send ID + 2 bytes for outputs and then wait for 2 bytes for input states so a total transmission would be 5 bytes per slave. So for 5 slaves that would be a total transmission of 25 bytes to exhange all IO information with just 1 bus.

With my method it is just 2 bytes per slave + 1. Which will be 11 bytes. + I do not need separate ID's. So no unique software versions, no eeprom usage to store an ID, no hardware address pins. I can easily change out slaves without problems. Regardless of how you would use your max485 modules, this method will always be faster.

That's great if you have uniform slaves and if you want to request data from all slaves every time.

The speed depends largely on the delay every slave adds when forwarding the data.
Not having IDs is not appreciable in every situation.

This is almost insulting. I am not confused of anything. First of all I did not know how arduino handled the hardware serial library precicsely. That is why I was asking about this. I do know that they used buffers and interrupts. But there is more than 1 way to handle interrupts.

I don't see what this is insulting (may be because I'm not a native speaker).
You wrote about the hardware serial library is not considered efficient. I never read that yet, but the SoftwareSerial library is often criticized for that, so my conclusion. It was far from being offensive.

Ofcourse it helps to know if a slave is not functioning properly, why would this not be helpful?

You usually assume the same if a slave don't answer to requests on a "traditional" bus.

And I can think of ways of recovering. I reserve 6 bits for adrresses I can embed 2 control bits, with which I could implement a reconnection attempt or something.

If a slave is failing part of your bus is failing (it doesn't forward the bits anymore to the next slave), so in my view this is a big drawback of that concept.

[Robin2]

bask185:
However every device needs to be able to receive and transmit simultaneously.

Nothing in an Atmega microchip happens simultaneously because there is only on microprocessorr. However it can perform fast enough to give the impression to a human that things are happening simultaneously.

I think you are confusing the baud rate with the data-throughput - the number of messages per second.

Clearly the baud rate has an affect on throughput, but it is only part of the equation. The number of bytes in a single message and the amount of processing that needs to happen with a message are also significant factors.

Start with a modest baud rate and see how many messages per second your system can manage. Then see if a higher baud rate improves things.

...R

[bask185]

I developed some initial code for a slave. I still have to check the IO logic though I believe that this should do the trick

void SerialEvent() {
 static byte packetSize = 0;
 static byte byteCounter = 0;
 static byte forMe = 0;

 byte serialByte = Serial.read();

 if(byteCounter == 0) { // first byte
 forMe = (serialByte & ADDRESS_MASK) * 2 + 2; // store which bytes are ment for me
 mode = (serialByte & ~ADDRESS_MASK) >> 6;    // fetches the mode (io update, scan round, iodir message, extra future)
 serialByte += 1; } // increment the first byte by 1 for the next arduino so he also knows which bytes are for him

 else if(byteCounter == 1){ // 2nd byte contains the 'packet size'
 packetSize = serialByte; } 

 else if(byteCounter == forMe) { // 2 bytes are reserved for IO updates
 byte tmp;

 tmp = serialByte & GPIO_MASK_A;   // copy the output bits in tmp
 serialByte = GPIO_A & ~GPIO_MASK_A; // set serialByte with the input bits
 
 switch (mode) {
 case DEFAULT: GPIO_A |= tmp; break; // or the IO port (not the actual port) with the the output content of the serialByte
 case SCAN: break;
 case TRISTATE: IODIR_A = serialByte; break;
 case EXTRA: break; }
 
 else if(byteCounter == (forMe + 1)) { // byte is for me
 byte tmp;

 // at this point the serial byte only contains information for the outputs
 tmp = serialByte & GPIO_MASK_B;   // copy the output bits in tmp
 serialByte = GPIO_B & ~GPIO_MASK_B; // set the serialByte with the input bits
 
 switch (mode) {
 case DEFAULT: GPIO_B = tmp; break; // update the IO port
 case SCAN: break; // not yet developed, this case might be redundant as the master needs to sent just 2 bytes for a scan round
 case TRISTATE: IODIR_B = serialByte; break; // upon booting io direction information will be distributed
 case EXTRA: break; } // future use
 
 Serial.write(serialByte); // echo byte to the next device

 byteCounter += 1;
 if(byteCounter == packetSize) { // last byte transceived, start over for next packet
 byteCounter = 0; } }

GPIO_A and B are not the actual IO ports ofc. They are byte variables which are used in the main loop to update the actual IO. This part is not yet ready. I need to do some bit shifiting as I cannot use port B pin 0 and 1.

As of this point the slaves only have to exchange information about 16 gpio pins. If I want to use something else I'd use the i2C bus for extra equipment.

The first implementation will be used for a very long modeltrack. The default S88 bus (which is incredibly expensive) is very susceptable for EMC.

As for the master. I am aware of the performance problem which may present a problem at 250.000 bps. It is unlikly that the master will be able to handle much else.

Therefor I want to make the master device with 2 arduino's of which the bus driver is programmed as an I2C slave to the other arduino. This I2C slave will continously drive the serial bus so all IO linked to the bus are up-to-date.

However as for the modeltrack, the sole purpose of the bus master is to relay the input information from the serial bus to the controller to which it is attached.

If I would use 5 slaves. A transmission would exist out of 12 bytes (5 x 2 + 2). To clock them out takes about ~1ms at 115200bps. And every slave will create a tiny little bit of lag. But it shouldn't be that much. Even if it would take another ms to read the packet back in it is more than enough speed for our typical hobby application.

The I2C master can send and request IO information of the entire bus at will, just like you do with a typical I2C IO extender. If the I2C master is interested in just one input of one slave, it may request just one byte of the bus driving I2C slave via the I2C bus.

MorganS:
Your initial description sounds like what WS2812 addressable LEDs do. But backwards. That starts with the number of LEDs and counts down to zero.

But if I understand correctly, it are the WS2812 who are doing it backwards

MorganS:
If the master wants to read a byte from a slave then it must send an empty byte addressed to that slave for it to modify? That sounds like SPI except with a lot more overhead.

The master is never interrested in what one single slave has to say. The master sends out an package with output information for every slave. Every slave has the ability to add his input information to the package on the fly. This can all happen with the same bytes. If the outputs of the port are 0x0F, than the inputs are the other 4 bits. The master does this continously. There is no data polling, every line works half duplex so there is no risk of data collisions. As such there is no actual overhead needed to prevent message from corrupting one another.

The only thing that I should be aware of is that the master sends bytes slightly faster than the slaves can handle. The slaves first have to swap-out the content before relaying the message. As such the receiving buffer could theoretically overflow.

MorganS:
The maximum speed and length depends on the characteristics of the transmission line. I suggest you read up on impedance matching theory.

Why would I do that? I've already had the theory on college. The max485 are more than capable of running @250kHz. I also to put 120R resistors on every bus end.

MorganS:
"As fast as possible" is not a specification. How fast do you need? Select a technology which can go that fast. Modern plant control networks use Ethernet because the hardware is cheap and some of the devices like machine-vision cameras are sending megabits per second of data.

You are 100% correct. ASAP is not an specification. It is a question I've asked what the maximum possible baudrate would be for my particular use-case

The only specifications are the use of: atmega328P and max485 ICs.

Robin2:
Nothing in an Atmega microchip happens simultaneously because there is only on microprocessorr.

I am pritty sure this is not entirely true. Well it is for as far as the code goes. The microprocessor is just one device. It comes with periphical devices like the USART which I am using. After loading a byte in the transmit buffer in our software, this device does the outclocking part while we can do other things with the software.

I think you are confusing the baud rate with the data-throughput - the number of messages per second.

Why do people keep saying I am confused? I am not confused of anything.

P.S.
I have also thought of a simple node unit which can be used to split the bus using an extra max485 and a mux. I should be able to make several splits on the bus without problems

[Robin2]

bask185:
I am pritty sure this is not entirely true. Well it is for as far as the code goes.

The code is the part I was thinking of.

The fact that bits might be sent or received in the background is of little relevance to the logic of a program. When the bits coalesce into a byte the microprocessor is called.

...R

[Paul_KD7HB]

Until the OP actually has something running, then I will become interested. Right now, it's all smoke.

Paul

[lastchancename]

Whoa there.
Your diagram indicates you’re using ATMega328s.
The 328 chip only has ONE hardware serial port.
None of what you’re planning will work with a software serial port, and an off-chip serial UART will use pins and cycles to implement.

[MorganS]

A typical bus has a variety of things on it. A temperature sensor you want to read once per second and maybe an accelerometer you want to read at a consistent 1000Hz. Having to read all slaves all the time is a problem for that mix of bus devices.

And default I2C is slow. SPI would be better for the bus master transceiver.

[krupski]

bask185:
Now the questions.

I'd like to have this running as fast as possible. I've read that the maximum baudrate of 2M for an atmega328P can be realized. However every device needs to be able to receive and transmit simultaneously. So I believe this might influence the performance too negatively?

What would the highest achiefable baudrate transceive full duplex?

I don't know if this will be of any help, but what I've done with 328P and 2560 based boards (using either a direct TTL serial to serial link or a serial FTDI232RL link) I've gotten reliable full duplex data transfer at up to 1843200 bits per second using my own interrupt driven and buffered serial code and the AVR USART.

I did find that communication became unreliable if the link (wire) length was over around 3 feet (1 meter). Using a twisted pair solved this problem (initially tested with 1/4 of a CAT-5 ethernet cable and then with a home made twisted pair).

This worked flawlessly as far as I tested (20 feet or 6.5 meters).

The only thing to watch out for is the 16U2 USB to serial chip on the Arduino boards. These barely can handle 115200 bits per second. A direct link or a good USB to serial chip like the FTDI232RL works at any speed.

And, as MorganS said, SPI may be an even better (and faster) choice. Still may need twisted pairs though.

[bask185]

lastchancename:
Whoa there.
The 328 chip only has ONE hardware serial port.

I only need one serial port. The Tx/Rx pins are split into separate rs485 busses, the Rx goes to the previous arduino and the Tx goes on to the next Arduino. If the arduino is the last arduino the tx will go back all the way to the Rx of the master. Every 485 bus as I implement is just one way traffic.

MorganS:
A typical bus has a variety of things on it. A temperature sensor you want to read once per second and maybe an accelerometer you want to read at a consistent 1000Hz. Having to read all slaves all the time is a problem for that mix of bus devices.

I am sorry but this is a bit nonsense. There is no relation to the bus frequency and the sample frequency. That the slave has to read and send bytes @ 1kHz or faster does not mean the slave also has to read it's sensor in the same frequency. The slave can easily send the last taken sample for over a second, than take a new sample and send that sample for the next second.

MorganS:
And default I2C is slow. SPI would be better for the bus master transceiver.

Valid arguement! I've found on mr Gammon's website a nice example.

You made me think of something:
I do like the idea that I could run an I2C address scan upon booting and link addresses to certain devices. Than a slave can know if it has an I2C sensor attached (given the 1 condition that sensors don't share the same address). Ofcourse the master still has 16 bits left to tell that slave what kind of sensor he has.

At the moment however I am not interested in the sensors. But I always tend to create modular software so I will make my software suitable to "plug-in" new sensors for future purposes.

There is also more stuff to think of, servo motors expansions (with I2C PCA 9685) and stepper motors would also be a neat add-on.

krupski:
I don't know if this will be of any help, but what I've done with 328P and 2560 based boards (using either a direct TTL serial to serial link or a serial FTDI232RL link) I've gotten reliable full duplex data transfer at up to 1843200 bits per second using my own interrupt driven and buffered serial code and the AVR USART.

I did find that communication became unreliable if the link (wire) length was over around 3 feet (1 meter). Using a twisted pair solved this problem (initially tested with 1/4 of a CAT-5 ethernet cable and then with a home made twisted pair).

This worked flawlessly as far as I tested (20 feet or 6.5 meters).

The only thing to watch out for is the 16U2 USB to serial chip on the Arduino boards. These barely can handle 115200 bits per second. A direct link or a good USB to serial chip like the FTDI232RL works at any speed.

And, as MorganS said, SPI may be an even better (and faster) choice. Still may need twisted pairs though.

Interesting addition, very usefull.

I will have no problems with the usb-ttl chips. The bus driver master itself won't be connected with USB to anything.

The I2C SPI master arduino will be for the testing to send IO states to the monitor.

As I will be using 485 modules with differential voltages I want to start out with a flat-cable (because is cheap). I believe that this should suffice. But were I to have problems I'd switch to patch cables instead as Plan B

Paul_KD7HB:
Until the OP actually has something running, then I will become interested. Right now, it's all smoke.

Would 1 bus with 2 slaves without 485 on a breadboard suffice? (communication prococol remains the same) I need to order some things from the internet but it will take atleast 3 weeks...

[Robin2]

bask185:
I need to order some things from the internet but it will take atleast 3 weeks...

Can't you find a supplier that will have the stuff with you in 3 days?

...R

[bask185]

I know atleast 3 suppliers which can get me my stuff tomorrow but the price is atleast 4x greater not to mention the shipping costs...

For the train club (<- for which mininum costs is an absolute requirement) I ordered 5 nanos, 5 DIY base shields (with screw terminals), 10 rj45 connector breakout boards (I decided to ditch the flatcable) and 10 max485 modules. It costs us around~$42,- and I can solder everything on a single PCB. Power will be supplied via the ethernet cables and the train occupancy detectors can be directly attached to the screw terminals. I'll also make an extra connector to add an MCP23017 in the future for 16 more IO pins. (therefor I also want to increase the packet size to 4 bytes per slave)

I was thinking of letting Pin 13 of every slave unconnected and configure it as an output. Than I want to write the led pins of every slave high and low in order every half second. So I can verify that the output side of the bus is working.

The bus driver arduino only has to act as a shift register (for the marklin S88 bus) and relay all input information to the central station 3. All inputs should then be visible on the central station 3 unit.

I'll let you know as soon as it works

[Robin2]

bask185:
I know atleast 3 suppliers which can get me my stuff tomorrow but the price is atleast 4x greater

For some things 4 times greater is still not a lot of money.

...R

[lastchancename]

ok, with the half-duplex singe UART idea, but you’ll need to create some fancy async code to handle the messages in each node of the ring..
Basically, you’re recreating a ‘LAN’ at the lowest level

[bask185]

The code is really not that complicated. The usart is capable of receiving bytes while it is sending. The arduino library handles that part for you. Every last byte will be relayed, so the master will receive the exact same amount of bytes as it sends out. It will receive the first byte soon after the first is sent out. If the master is still sending at that point is completely irrelevant.

Not to be insulting or something but you seem to be rather pessimistic. I first got terminology-nazi'ed about the arduino not being able to receive and transmit bytes simultaneously and now this.

Robin2:
For some things 4 times greater is still not a lot of money.

What are you even trying to say with this?
This does not contribute anything to the topic you know?

4 x 42$ = 168$
That is 126$ more than what I paid for now. This is about 25% of our entire year's budget for our track. I am not going to sponsor this myself, but our club has her arms always open for new sponsors and as you seem not not to give 2 dimes about $126 I'd like to welcome you to sponsor us. We will put your name, or your companies name on one of the wagons if you like.

Besides the tracks will not be even finished yet before I finish my modules... it is a slow paced hobby.

I also own an original uno but fact still remains that they cost like ~$25 when they are like <2$ to manufacture and now we get to buy one for even less than that. Our modeltrain companies also sell the most expensive pieces of electronics. I own 4 original Marklin breaking module which cost 67€ today. Inside there is a tiny PCB with 1 relais and a few R and C. I'd guess it takes them also around $2 to manufacture them. Perhaps if arduino boards weren't so incredibly expensive people would buy more originals. I don't mind paying a tad more or to donate some dough, but when companies start with over-exaggerating their prices......