To see this working, head to your live site.

LocoFi protocol

LocoFi is claimed to be an "open standard":

LocoFi | The Future of Model Railroading

So where can I find this standard - i.e. communcation protocol, so that one can write custom app to control multiple locomotives, or implement custom decoders that can communicate in the LocoFi protocol?

4 comments

Comments (4)

Matthew Caron

May 04, 2021

So, I've been doing industrial control systems (that is, hardware and firmware, not actually running factories on them - the controls engineers buy my stuff and then do their systems) and I was really interested in OpenLCB.. right until I saw that it's basically CAN-bus with Ethernet bridges. Given the state of the industry, I don't see why one wouldn't just use a completely Ethernet based system, likely with something like MQTT as a message bus. Then you can have your head end be basically anything that talks MQTT - I'm looking at NodeRED on an RPi for panel control, because my son wants tactile things (no screens) and the drag and drop flow control would make programming it easy.

As far as integrating with the API, I'll be dropping you folks an email to the address above - I want to bounce some ideas off you in the above regard. It may make sense to implement callers / listeners to / from your API as a NodeRED module and then Bob's your uncle.

Admin

Feb 24, 2021

Hello Mark,

Thank you for expressing your interest in implementing your custom app based on LocoFi™. There are two levels of customizations you can do:

1. Implement your own firmware as well as the controlling software. All you need is our hardware and freely available Arduino software platform. You will code up the firmware for ESP8266 or ESP8285 for the firmware and also need to develop an application software that will run on your choice of WiFi enabled device.

2. The other option is to use our hardware and firmware. We will provide you with the API (or commands) to our firmware and you need to only develop your application software. The benefit is that you don't need to write firmware but then you are limited by what we offer.

We are constantly improving our firmware with new APIs being added constantly that add to the existing functionality. Most of the times, all the changes are backwards compatible but there are times when the application software may need some tweaking to accommodate the changes. That is the primary reason we have not "publicly" published our APIs.

However, if anyone is interested and willing to work with us, they are more than welcome to e-mail us at wifimodelrailroad@gmail.com and ask. We will be more than happy to provide the necessary information.

We hope that helps. Hoping to hear from you soon.

Best regards,

LocoFi™ Team

mark.farnell

Mar 01, 2021

Replying to

When you say "hardware", do you mean decoder hardware? And "firmware" do you mean the decoder firmware?

And when you say "software", do you mean software on a computer or on a mobile device that controls one ore more vehicle-mounted decoders?

One of the use cases are to have a central control station that oversees the entire layout - including all rail vehicles, points, as well as sections , where the rail vehicles will be controlled wirelessly - like the control centre in a real railway. So one would need to have a published protocol in order to develop this type of custom control station software.

By the way, NMRA is developng the platform neutral OpenLCB open protocol:

that also allows for the OpenLCB be on any type of buses, including ethernet and wireless. Do you have plans to make LocoFi be compatible with OpenLCB, or becoming an extension of OpenLCB that is over WiFi?

I think this is the best way forward.

Admin

Mar 01, 2021

Replying to

@mark.farnell >When you say "hardware", do you mean decoder hardware?

Yes.

>And "firmware" do you mean the decoder firmware?

Yes.

>And when you say "software", do you mean software on a computer or on a mobile device that controls one ore more vehicle-mounted decoders?

Yes.

LocoFi™ is based on the distributed computing architecture. The availability of cheap and powerful hardware has made this possible. With communication speeds approaching Gigabits per second, information travels quickly. This has made the central server kind of systems obsolete where you need one central powerful piece of hardware and if it goes down takes the entire system down with it. Moreover, IoT is already connecting billions of devices that may not even be from the same genre. We like to give the example of a scheduled train that passes under a coffee pot (think coal) and goes around to serve you morning coffee at your table, all devices being part of the IoT domain.

However, being open standards based hardware, a custom protocol can always be implemented. We certainly have plans to integrate with not only OpenLCB but DCC and JMRI among others. And to that effect, we invite community members who are willing to take the plunge.