Designing model train layout I/O and PWM speed control

[C]

Instead of new thing might work

Would be better to have more details and get to this change should work.

Are those just pretty pictures or does it work now?
What can it do now?
What controls the engine now.
How is track wired now.
More details the better.

If the engines can not be changed, need to know what the engine needs to work.
What is it using now.

You stated that

DCC is out of the question unfortunately as the locos are all hand built (about AUD$500 each) and have no space inside the resin bodies to fit the DCC components - this is the first option I looked at. The smaller N gauge trains are even smaller inside.

Some motors do not like some signals and long term use harms the motor.
The more details, the lower the chance of harm.

Look at big picture
You want to control old engines.
You want to update old control system.
Do you really care the how if it works if new control is better then old and does not harm engines?

Look at simple led's for example
One bit can control on or off.
With 3 bits and RGB color led you have 7 colors
With 3 connections and RGB color led Three PWM signals gives you lots of colors.

At some point with lots of RGB color leds it's cheaper and better to use special led controller chip.

Final step is
The APA102 is a RGB color led with internal controller chip.
The controller chip logic is built in a way that lets you have long strings of APA102 with out needing buffers.
If you watched that video, it uses 4 8 bit values to control led.
The APA102 uses two inputs for control, data & clock.

The WS2812B RGB led uses one signal where time and level controls led.

So back to engine

Safe for engine motor could be a DC voltage with positive one direction and negative other direction.

So a lot of details of what exists now is good first step.
Power source details all the way to engine.

 

[ilium007]

These are just pretty pictures at the moment, nothing is working as yet. This has been a 30 year project for my Dad and the first time he has had a chance to build a train layout.

Nothing controls the complete layout now, we have been running the loco's on a 40 year old Thrysistor speed controller on one active loop of the board.

None of the yard switching is seperate so only one train has been run at a time during the lay down of the tracks.

Track has "droppers" (one to each track) from the top of the board to the bottom at the points indicated by vertical arrows on the "pretty picture"  previously posted.

The locos run on a 12VDC power supply, previously this was just a 240V -> 12V transformer with a variable speed control. Recently I prototyped a 20kHz PWM solution that used a non-linear speed curve that I developed that ran all locos without issue around the track.

I have no technical details of the electric motors in the locos - some of these were purchased when I was a 15 year kid (19 years ago).

Do you really care the how if it works if new control is better then old and does not harm engines?

Not really, but as previously stated I am using this as a hobby / learning experience. If I wanted to buy off the shelf components I would have just gone a dropped $$$ on a full DCC system and told Dad to go and buy new trains. Thats not what I am trying to achieve here.

Safe for engine motor could be a DC voltage with positive one direction and negative other direction.

Probably correct, but I don't have the skills to build a non PWM speed control circuit. I have no formal electronics engineering education or background. I have looked at many non PWM circuit designs that I could just copy that would give a 0v -> 12v  with a FWD / REV switch but I am not sure how I choose one to simply copy. I still run into a few issues with this arrangement, ie. someone (my 4 year old) running a train from one track in FWD to the next segment in REV = smoke.

I'm happy to continue on the path of getting a PWM solution working, learning along the way and yes, probably spending more money that buying something off the shelf.

[Ian.M]

I can see a problem with that layout.  There aren't enough insulating fish plates.  It needs them in the two orange tracks just to the left of the points in the top left right corner so you can hold a train at a signal on the track that isn't selected  by the points.  That would also require a power feed to the right side of the outer loop.

You also need to understand the difference between live frog and dead frog points, and their impact on which branch track gets powered.  See http://www.brian-lambert.co.uk/Electrical.html#Points.  I'm not sure what the P and D marks at the points code - maybe its live vs dead frog?

At the moment I count 6 power feeds to the orange track (ignoring the questionable one) and none to the green.  With a feed to the green + an extra feed as I just proposed for the right side outer loop, that's eight feeds.   If you use 8 H-bridges that can be paralleled  you can control each independently or sync them up for continuous loop running.   There are four more feed points in the inner layout, so if you want to avoid relay switching, you'd need 12 H-bridges.  Their cost is heavily dependent on the   Maybe look at the dirt cheap classic L298 dual H-bridge.  It can drive up to 2A each, or 3A (3.5A repetitive peak) when paralleled as a single H-bridge.    I believe the rule of thumb is up to 1A per loco, so unless you are planning on running double-headed trains, you could probably get away with half the number of L298s as yiu have feed points.  They are less efficient than modern MOSFET H-bridges so you need a bit more than 12V in to allow for the losses + a big heatsink, but if you can salvage the heatsink, six L298s (or eight to allow for future expansion) + the afore-mentioned MT8816 crosspoint switch, would be a very good option for four control channels with switched current sensing feedback so the controller always 'sees' the peak current of all the L298 sections that channels is driving.  Add a comparator for fast shutdown local to each L298 and it would be short-circuit proof.

Re 'kindness' to old motors of PWM signals - there's no reason why you couldn't add L-C filtering to the H-bridge outputs to average the PWM signals.  just keep them symmetrical - use a pair of equal inductors  in series with the H-bridge outputs and a capacitor between them just before the wiring goes off to the track.  SOME ripple is beneficial for permanent magnet motors - it combats stiction and aids reliable low speed running, but reducing the HF content will reduce motor heating and also peak voltages that might cause rotor insulation breakdown.

Edit: Sorry for the left/right confusion. See below.

[ilium007]

I can see a problem with that layout.  There aren't enough insulating fish plates.  It needs them in the two orange tracks just to the left of the points in the top left corner so you can hold a train at a signal on the track that isn't selected  by the points.  That would also require a power feed to the right side of the outer loop.

It was a mistake on the diagram, there isn't a set of points there. The outside orange loop runs all the way around and is insulated where I have now drawn the black lines across the tracks.

You also need to understand the difference between live frog and dead frog points, and their impact on which branch track gets powered.  See http://www.brian-lambert.co.uk/Electrical.html#Points.  I'm not sure what the P and D marks at the points code - maybe its live vs dead frog?

Yes - I omitted the P/D nomenclature. This mud map was just for my initial design. P is a Peco point which is a dead frog (points make and break the track circuit), D was for "Dual Gauge" point - the orange track is actually dual gauge (makes no difference to this conversation - I noted there becuase htese are points I'm moving with servos) and the dual gauge points are all live frog types hence the insulating fishplates after them.

At the moment I count 6 power feeds to the orange track (ignoring the questionable one) and none to the green.

Missed the green power feed off the diagram ! Because they are all dead frog points the points will make and break the contacts to each track segment when they are switched. Orange track outside loop really only needs 1 PWM feed (Dad just put the others in because... I don't know why!).

With a feed to the green + an extra feed as I just proposed for the right side outer loop, that's eight feeds.

I believe I only require 3 PWM H-Bridges (shown on updated diagram below), one for each of orange, yellow and green and a DPST relay for each dashed segment plus the one solid segment in orange and yellow sections as shown.

The problem of parallel H-Bridges only appears in the sections in the red boxes doesn't it ?

Re 'kindness' to old motors of PWM signals - there's no reason why you couldn't add L-C filtering to the H-bridge outputs to average the PWM signals.  just keep them symmetrical - use a pair of equal inductors  in series with the H-bridge outputs and a capacitor between them just before the wiring goes off to the track.  SOME ripple is beneficial for permanent magnet motors - it combats stiction and aids reliable low speed running, but reducing the HF content will reduce motor heating and also peak voltages that might cause rotor insulation breakdown.

I will look in to this - I had seen reference to the L-C filtering in my initial research some months back.



I'll head over to Dad's tomorrow and redraw this whole thing a bit nicer and confirm that it is all correct.

[C]

Your  4 year old  says to you " Daddy I tried to do a head on collision with two engines, it did not work"
A sign of good control system.
Building system can cost more but you gain in knowledge and control.

Little details can matter.
You know that engine gets power from track.
Here the HOW can be important.
With out details the safe answer is any one or more wheels on each side.
(#1)With this detail you could have one wheel at front and one wheel at back of engine supplying power.
(#2)You could have a axle at front and axle at back with sides connected.
Not knowing where train is in block leads to
Not powered next block or matching power.
With not powered
#1 would stop and #2 would power the block until all wheels are in new block.
You can sense both states with proper circuit. In addition to smoke prevention control system gains train in block info.
A voltage sensor to each rail would work here.

With  matching power
you have a current change to one or both current sensors connected to block rails.
 
If you add two of both types of sensors to a block then you do not care what wheels engine uses as all engines are safe.
Using less than 4 sensors you have to specific wheel connections.

To prevent smoke the electronics needs information so that it can prevent smoke.
An example is a good bench power supply that has a current limit.
Too much current, turn off power supply = no smoke.
A better choice for trains is limit current to very low value so that you can sense if engine backs up.

Using the sensors you collect facts. Some the hardware uses, some the software uses. All preventing the smoke.

So you know High frequency PWM can cause heat in motor.
The old variable speed control with  Thrysistor could be partial part of AC cycle, this would be low frequency PWM.

So  you now have my simple answer
&
lan.M's with more detail

[Ian.M]

Ok, that's pretty much what I thought apart from the P vs D confusion. Also you wouldn't know it but due to dyspraxia I can totally confuse right and left. I was referring to adding insulating fishplates top RIGHT, but typed left. 

To get anything into or out of the green sidings you'd have to either switch both to the same controller or precisely sync the PWMs.    The mod I suggested earlier to isolate both branches of the top right orange points would make it much more versatile as then you could switch the inner orange tracks to the green controller for ease of shunting while still running a train on the outer orange loop.

If 2A is enough current per train, half a L298D + ancillary components will almost certainly work out cheaper than a reasonable quality socketed relay.

You could also poll the track for train positions using the current sensor without moving anything - just briefly apply a very narrow duty cycle PWM to each section in turn and look at its current sense signal to see if there is a load present.   However you'd do better to have some sort of active sensing (e.g. optical) guarding critical points like where sidings join a track that can be configured as a continuous loop so it can E-stop the shunting controller if a cack-handed train movement is about to result in a conflict or crash.

[C]

When you go over to dad's
really look at the track for insulators in the rail.
The more you have the more you can sense.
Might want to take an ohm meter and measure track joints.

Look at yellow spots where you put DPST
Guess is that is engine parking spots.
lan.M suggested using controller to do low current sense if train is parked.
If one side of DPST is off, you could change off to low current sense from a power supply to detect train.

[MarkF]

I thought it may be helpful if I present my HO layout and design.  Some design details are discussed in another thread.  IMHO the large shift register design is the wrong way to go.  One, the long time it takes to update the I/O and the fact that you must update all of it (no partial updates).  Two, the railroad layout is a noisy environment and it only takes a little noise on the clock line to offset your entire I/O bits.

My computer interface centers around a DLP Design module which is quite old and expensive. The basic I/O is parallel address and data buses.  You may want to modify the addressing to allow more I/O (boards).

• Computer USB Interface Board (IO-1.png)
• Track Power Board (3 boards to 30 track blocks)(IO-2.png)
• Relay Driver and Senor Board (3 boards)(IO-3.png)
• Track Driver Board (30 boards)
• Tortoise Slow Motion Turnout Board (45 boards)

The Track Power board generates a combination of a PWM waveform for low speed control or a pure DC voltage for high speeds.  Each PIC16F876A controls 2 track blocks with direction control and track short (train wreck) sensing.  Each PIC has speed settings, error flags and firmware version query responese to the main computer.

Each Relay/Sensor board has 15 relay drivers (ULN2003) and 15 TTL level sensor inputs for block occupancy detection.

Track Crossing indictors (lights or LEDs) are with the extra contacts on the switch machine.

Wireless Hand Throttles (not shown) based on the nRF24L01+ RF module will allow up to 5 users at one time.

  Don't know if this helps your design.  Just food for thought.

[ilium007]

I thought I'd spend some time this morning having a look at I/O options other than the shift registers. This IC caught my eye - the NXP PCA9698. It has 40 I/O channels and very nice current sink ability:

The PCA9698 provides 40-bit parallel input/output (I/O) port expansion for I²C-bus applications organized in 5 banks of 8 I/Os. At 5 V supply voltage, the outputs are capable of sourcing 10 mA and sinking 25 mA with a total package load of 1 A to allow direct driving of 40 LEDs. Any of the 40 I/O ports can be configured as an input or output.

I am going to look briefly at driving one via RS485 to the I/O board and then I2C to the PCA9698 on the board only.

The PWM control was doing my head in so I'm switching my attention back to I/O !

Back in the other thread Ian.M gave me similar advice !

If you want to be able to do long runs between boards, consider putting local intelligence on each relay board (or cluster of relay boards) and using RS485 line drivers and the MODBUS protocol, then you can setup a multi-drop bus over readily available twisted pair cable and power them over the same cable. e.g  if you use Ethernet cable, with one pair for data, and three pairs for power/ground, you can deliver 1A to remote boards with no issues.  Local regulation at the remote board is strongly recommended.

I'm looking at the MODBUS protocol now to see if I am going to have the skills to implement. I could put something like the PCA9698 or the TPIC6C595/74HC165 shift registers on a remote board with an ATMega and talk to them remotely with MODBUS over RS485.

[David Hess]

I do not know if it has been mentioned but the ground loops from mixing the signal and power ground can cause problems and may even be destructive if a high current circuit opens.  Basic precautions should be taken like current limiting for logic signal inputs and outputs and I might preemptively use optical isolation.

[ilium007]

I do not know if it has been mentioned but the ground loops from mixing the signal and power ground can cause problems and may even be destructive if a high current circuit opens.  Basic precautions should be taken like current limiting for logic signal inputs and outputs and I might preemptively use optical isolation.

OK thanks, more research required. One thing I need to learn more about are common grounds, and then how to seperate ground planes between signalling and power circuits.

[ilium007]

So I have spent another whole day researching this.... I have concluded that a more robust interconnect is probably warranted (due to noise / interference) and RS485 seems to be an obvious choice here. If I go with RS485 I will need a protocol to talk over that hardware, MODBUS, SNAP and ICSC protocols all came up in my searches.

MODBUS seems to be quite complex for what I want - all I require is to send a bunch of outputs HIGH/LOW and read a bunch of inputs back to the main MCU. SNAP (http://www.hth.com/snap/) and ICSC (https://github.com/MajenkoLibraries/ICSC) both have little representation on the internet in the Maker scene. This part of the design would be a sticking point for me as I have never implemented or worked with any bus protocol.

At the risk of ruffling feathers I went back and looked at the MCP23S17 IC as well  Hear me out ! If I were to put a small low cost MCU on the expander board, ARM (Teensy LC) or AVR (ATMega 328p) - not sure yet, I could talk from it to the local MCP23S17's via SPI (keep everything on the board traces) and then talk to the remote boards via RS485 - MCU to MCU over some sort of bus protocol. There seem to be many projects online where people are successfully using the MCP23S17.

If I went down this path I would require additional components to increase current sink capability of the MCP23S17 such as the ULN2803 Darlington array (4 per board) or an N-channel MOSFET based approach (32 x 2N7002 per board).

I am not sure if this is a better / more robust approach than the shift registers over an SPI line that run underneath the layout board but it sounds more robust and less prone to interference. Again, I am keen to implement a solution that I can use for other remote I/O projects.

How does one choose a protocol to run over RS485 ? If I did it this way I would run 2 x MCP23S17's on each board giving 32 I/O per remote board (plus whatever I/O is on the MCU).

Would I still be doing a frequent poll of the remote input boards and if so, would the overhead of RS485 and whatever protocol I use mean it would then take too much time to request a slave to send its 32-bit input state back to the main MCU ? Given RS485 is a MASTER -> SLAVE system I could not have a slave MCU initiate a data transfer when someone pressed a button because it would end up in collisions on the serial line.

Looking forward to hearing peoples opinions on this approach 

[C]

You have an event bus

Use CAN this is what it is built for
Cars are very noisy

With RS485 you have problem when can device talk
Problem CAN does not have this problem and gets job done.

[ilium007]

CAN bus seems very complex.... I'll start looking in to it though.

[C]

Would I still be doing a frequent poll of the remote input boards and if so, would the overhead of RS-485 and whatever protocol I use mean it would then take too much time to request a slave to send its 32-bit input state back to the main MCU ? Given RS-485 is a MASTER -> SLAVE system I could not have a slave MCU initiate a data transfer when someone pressed a button because it would end up in collisions on the serial line.

CAN lets you use the power of the slaves

CAN is not complex if you understand it.

First the can controller handles problem when two what to talk
They use fancy names but you could think of that CAN transceiver chip as being like an open collector output in TTL logic   Two outputs on is not a problem.
 CAN transceiver has output of what is happening on the wires and the CAN controller listens to it's self talk.
Think of what happens when two people try to talk at same time, you back off.an try again. 
The CAN controller that wins when more then one tries to talk has the highest priority and keeps talking. It's simple, the logic is such that it is only one that  seeing what it is saying.

Re look at it this way
  You have an input out on the track that just changed.
That input has a type, so you have some bits for the type.
That input was collected by a slave, you have slave bits
That input was one of many like inputs, you have input number.
The CAN ID bits is
Input_type, slave#, input#
The CAN Data
  need one bit for on/off   there are 8 bytes max
  If data is a number like temp, voltage, current  send the number as data.


A good CAN microcontroller will let you program or reprogram the chip over the can bus.  One CAN controller could reprogram all the CPU's in the system.

If you have looked at YouTube
You might have seen where  a ESP32 wifi controller was reprogrammed over the air by  Arduino IDE

If that ESP32 has the code to program over CAN you could re-program all.

Your Teensy has a CAN controller in it.
With code to program over CAN you could re-program all.

[ilium007]

Thanks for the reply, I'm reading the wiki article on CAN bus now.

[C]

Remember this

Your  4 year old  says to you " Daddy I tried to do a head on collision with two engines, it did not work"
A sign of good control system.

Two of the slave microcontrollers see the problem.
Both at same time try to scream out a high priority CAN packet.

Just a normal every day thing for CAN, highest high priority CAN packet UN damaged went on CAN bus and all could receive it.

The delay is waiting for previous on wire packet to complete.
   Then is why a CAN packet is small.
 Waiting for even higher high priority CAN packet to complete.

So you have to think,  if something like a create smoke event could happen, you want it's CAN ID to have a higher priority then a "this block is occupied"  packet.

CAN is an EVENT bus with  priority, and was built for this all the way down to the wires.
IT is not some way to talk on bus with events tacked on top.
Ethernet fits in this category of "NOT Built for events".

[Ian.M]

CAN is complex, but if the MCU manufacturer has a good protocol stack for it, that removes much of the pain - call a few functions to initialise it and transfer data, and register some callbacks for event handling.

However, if you are sticking with RS485, a MCP23S17 gives you 16 bits of I/O for $1.26.  You still need to add a MCU to talk <whatever> protocol over RS485 and control the MCP23S17 via SPI.   If you don't want to have to reinvent the wheel you'll need one with a hardware UART and SPI port, so you can use an off-the-shelf library for a standard protocol and for the MCP23S17

An ATmega2560 MCU gives you about 80 I/Os (you loose a few to the crystal, Reset, and the UART for the RS485, and costs you about $12.   That's only $6.25 more than the cost of five MCP23S17,  but you still haven't subtracted the cost of the MCU required by the MCP23S17 chips, or the cost of the board area they occupy so the real price difference is only a couple of bucks, and it may even come out in your favour.   If you use the Arduino IDE with the off-the-shelf Mega2560 board definition, you only get 54 pins, but with a custom board definition you can easily use the whole lot.

Polling will be fast enough - after all the MODBUS protocol was originally created for industrial automation, and running control panel buttons and indicators and far more time critical stuff like limit switches is a large part of that.   

To request a read all 80 pins of the ATmega2560 and get the reply could take as little as 13ms using the MODBUS RTU protocol at 19.2 Kbaud. 76 polls a second would saturate the bus, but half that would be more than adequate to provide a responsive user experience.  Put some smarts in the keyboard/panel MCU code so it queues keystrokes and you can poll it maybe as little as ten times a second, especially if it updates panel indicator lights locally, and shave a few bytes off the reply packet length.

Add another RS485 transceiver for a second slave to master serial port and  have it report its address and the keystroke, (not MODBUS protocol) and its even quicker, though in a multi peripheral MCU environment the auxiliary 'alert' bus is effectively multi-master so you then need code to listen to its own transmission, and if its corrupted, you have a bus collision so back-off (wait) for a random period and try again.  Repeated collisions should double the maximum back-off period each time, but the extra delay should be reset by a successful transmission.

If you need hard realtime event signalling without the complexity of CAN, each slave needs a dedicated interrupt line back to the master.    Or if its acceptable to poll several devices when an interrupt is received they could share an interrupt input.   There are some details that need to be taken care of for reliable signalling (i.e. *NOT* running single ended logic level signals down long wires), but there's no point discussing that if you don't need it.

[ilium007]

I like the idea of multi master communication with CAN bus over 2 wires. I’ll concentrate more research on that protocol.

The ATmega2560 is more expensive than the much more capable Teensy 3.6 (with 58 digital I/O and 58 interrupts). For the remote boards I could use the cheaper Teensy 3.1, still Cortex M4 based and has a single CAN module with good library support. All it needs is a 3.3v CAN transceiver.

I’ll spend some more time looking at the CAN code before I buy some parts to prototype.

[C]

CAN is only complex if you hake it so.
ilium007 has control, there is no need to match whole system to some CAN standard of how to talk.
CAN is a simple stream of BITts. Complexity comes from not using it the way it was designed to function. Or some standard poorly rewritten.

There have been many model train systems with CAN as control bus. Doing what ilium007 wants.

ilium007
Open your eyes a bit and look around.

Look at cost of an ESP32 on a board.
Look at cost of other boards that do CAN with controller inside MPU like your Teensy.
AVR CAN is high cost with low CPU power. I would not do simple PICs chips even with low cost chips.

If you are building the pc board and putting a micro controller on the board,
You have many choices from ST (STM32), NXT and lots of others.
But not dip chips.

You could go big time and use a $10 PSOC-5LP board.
Free programming environment 32 bit cortex & some FPGA if needed.

Think even the STM32 can be programmed now from   Arduino IDE now
If you look ST has a lot of low cost boards you can get.

[C]

ilium007
Think simple

You have one of many inputs change on one of your boards.
MPU reads the bit or value
looks up in a table and sends a stream of bytes to CAN Bus output buffer.

Simple CAN output driver sends the byte stream(packet).
Fancy CAN output driver sends the highest priority stream of bytes(packet) first

Simple CAN input driver gets a packet, a byte stream and puts it in a table.
This is an interrupt process.

A timer causes a input table check
Simple CAN table check calls a sub.
Fancy  CAN table check looks for highest priority and calls a sub.

Some CAN packets could need many subs and could create more CAN packets.

example
Operator changes switch
CAN packet sent
Track switch controller reads packet and changes a track switch.
Sends a CAN packet
Operator indicator controller reads packet and changes led.

Simple list processing, something a CPU is good at.

A CAN Packet causes a List to be processed.

An Event is the changing of an input or new value from a sensor causes a list to be processed.
Or a CAN packet event.

If a device creating a CAN packet also needs to local process packet it can be a simple add to receive table. this lets local & others cause same change using same code.

Want to add a crossing gate? That is a block sensor packet or a sensor that caused a CAN packet saying train is close to crossing.
 
Want to add sound effects? You have all the current CAN packets. You add to a list if you need something new.

[Leo Bodnar]

If you go CAN, plan well ahead on how you are going to manage assignment of unique IDs, especially if you use multiple nodes of the same type.
Serialising unique devices and managing dynamic CAN ID assignment is the most unpleasant of all CAN features.
CANopen has LSS and LMT but it's too heavy for a simple project like this.
Leo

[ilium007]

If you go CAN, plan well ahead on how you are going to manage assignment of unique IDs, especially if you use multiple nodes of the same type.
Serialising unique devices and managing dynamic CAN ID assignment is the most unpleasant of all CAN features.
CANopen has LSS and LMT but it's too heavy for a simple project like this.
Leo

I'm looking at this today, I don't quite understand how to implement message ID's for a particular message type. Let's say I have multiple block detection IR sensors that have to send a message back to the main MCU via CANbus. Do all of these have the same CANbus 11-bit ID ? What happens when 2 IR sensors send a message at the same time ?  Is a CANbus ID tied to a message type or is it used as a sort of node ID address ? I don't think it is the latter as the arbitration process could then block a node from sending because its ID is higher than another.

I'm finding it difficult to find a good tutorial on the topic as most people who have written about the topic just want an MCU on CANbus to eavesdrop their cars CANbus !

[C]

the easy answer is all CAN ID are unique

You never want two different CAN bus devices sending the same CAN ID
If you do then you have a bus fight.

Are you going to have more than 2000 different event?

Make it easy on your self
If each IR sensor has its own CAN ID then then your control system is easy.
The Can data is the state

Say you have an operator controller
Can ID would be what engine and can data what value
   

[ilium007]

Excellent, that helps ! I’ll buy some hardware and start testing.