Has anyone had any experience designing a SUSI device to attach to a decoder?

My reason for asking is that Minoks posting over here has reawakened thoughts of doing something similar.

Cogitating on it today my thinking is going along the following lines - Use a raspberry Pi Zero W as the primary camera control unit for a RPi camera, and it will then be able to store video on its internal microSD card and/or transmit it over Wifi to a phone or tablet.

Then have a potentiometer linked to the front coupling on the wagon - I am envisaging using a 4515 wagon as the underlying transport - which the code in the RPi will read and swing the camera in line with the bogie position so it will 'look around' curves as it travels.

However having watched the video in Minoks post I realise there is some value in unlinking the camera from the bogie angle and being able to turn it further manually to get sideways views. So my thoughts wandered along the lines of using a suitable decoder such as a Lokpilot as the source of control and link it to the RPi with a SUSI interface.

I have looked at the NMRA document which is essentially a translation of the German document by the originator of the SUSI protocol. It doesn't look like an onerous protocol in terms of timing, so it should be able to be decoded by the RPi with commands defined to lock the camera to the bogie, or move it independently, start recording, and any other functions that come to mind.

As another thought I was considering having some lights at the front of the wagon, which when turned on would 'fade up' over several seconds after a voice says "lights" then once they had come up to full brilliance the voice would say "Camera, and a couple of seconds later would say "action". this should be all possible with the RPi initiated by a SUSI command.

So I'm wondering if anyone has tried playing with SUSI beyond using ready made add-on boards?

I did it many times.
I use SUSI to get information from decoder and use them to control lights and other special effects.



This is an expansion board for Marklin and Hag Re460.
It takes information from SUSI about speed, direction, functions status and controls 8 amplified outputs per side, two servos for pantos, 4 LED outputs for panto sparking.
Besides, one relay is for consist lighting, the other is a latching relay for pickup shoe switching in shuttle trains.
It works with Lokpilot V4 and Zimo, but only F0-F12. It doesn't work with Marklin decoders, reason unknown.
The flexibility of Lokpilot programming is lost, all control of outputs is written into the board and cannot be changed by user.

I have also used this technique to control an entire consists from one decoder, passing the four SUSI wires all along the train.
It works but not perfectly, at power on everything works, after some running on rails (i.e. noise, spikes and so) the slave boards far from master lose control and a power off/on is needed.
Probably the alignment of SUSI packets is lost.

Regards

Thanks Mario. I don't think Marklin claim to have a SUSI interface, although they must do as I understand that the C-Sine locos with piggy back decoders (i.e. the early ESU based ones) use SUSI to communicate the loco speed etc between the decoder and the C-Sine electronics. So to use a Marklin decoder you may need to use whatever setup they use for C-Sine control.

Having looked at the Lokpilot info for SUSI I agree with you, all you get is that a function is turned off or on and some information about motor settings. I am expecting to use the decoder just to get a track interface, so that is all I need as I am not looking to do anything fancy.

How did you receive the SUSI data? It looks like it should be possible to use an SPI module in 8 bit mode, possibly using timeouts to deal with framing issues. Then using a transistor driven from a GPIO pin to pull the data line low for an acknowledge pulse.

Except the CV commands which are 3 bytes (24 bits). I guess if one presets everything and doesn't worry about CVs then it doesn't matter

Thanks for the scope shots, I hadn't got that far yet, but will confirm them for myself.

Regards

Alan

That might be a possibility, but what I am considering doing is using a PWM output from the RPi to provide the position command for an R/C servo. I was looking at having the RPi sense the bogie angle using a potentiometer, and then provide a calibrateable drive to the servo, as I believe the camera angle swing in bogie follow mode will need to be a greater angle than the bogie moves to produce a sensible view in the image. My gut feeling is if the bogie goes 5 degrees then the camera will need to move something like 8-10 degrees.

The idea of using a decoder to control the options is a very recent idea after watching the video that Minok posted the link to, and realising that there is viewing value in having the camera not just look straight ahead in track follow mode.

The sort of options I am thinking of are as follows: -
Camera in "Track Follow" mode - one function turns on this mode, a second function possibly increases the camera swing by a fixed amount.
Camera in "manual" mode (one function pans left, another function pans right). Possibly another function key would allow these ones to add offset to the track follow mode as you previously suggested.
"Record" video - RPi records the camera video (allows dropout free watching afterwards). The video is always transmitted on the Wifi.
Another key would initiate a "Lights" voice announcement (head lights fade up) then "Camera" announcement (turns on red light on top to show active camera, studio style) then "Action" announcement which drops into Record mode.

I'm guessing there will be other ideas as time goes by .

I think the unit in the link that Minok posted does what you suggest.

OK. SUSI gives me the ability to control the camera from the train controller. Otherwise all control has to be done via wifi through the RPi, which involves doing an app for the phone.

I am envisaging having it at an exhibition where the video can be put on a screen for the public to see, with the camera control being done by the person at the controller.

Could you use, instead of a slave susi device, a second decoder, listening on the same address? It can be an actual decoder or an arduino (dcc only) which you can directly program to act on the function changes.