Use of openlap with FTDI FT232 adapter on Linux

[godmar]

First, apologies for filing an issue when what I have is clearly a user question.

I have a Carrera D132 with CU v3.30. I bought a FT232 adapter and connected it to the CU. I can successfully run carreralib's demo so I have some confidence that my hardware setup is ok. On the host side the CU appears as /dev/ttyUSB0.

My question: with this setup (no Android involved as of yet) - is openlap of any use to me?

When I started the server it says: "Please select a Control Unit device. If no devices are listed, please make sure that Bluetooth and Location (for scanning Bluetooth devices) are enabled or you are using a suitable serial to USB OTG converter cable." It says in red "No connection" - "Settings" is not grayed out, but when I click on it, I see the Settings options - clicking on connections leads to an error page:

Error: Uncaught (in promise): TypeError: Cannot read property 'connectionTimeout' of null
TypeError: Cannot read property 'connectionTimeout' of null
    at SafeSubscriber._next (http://localhost:8100/build/main.js:2380:40)
    at SafeSubscriber.__tryOrSetError (http://localhost:8100/build/vendor.js:17998:16)
    at SafeSubscriber.next (http://localhost:8100/build/vendor.js:17938:27)
    at Subscriber._next (http://localhost:8100/build/vendor.js:17876:26)
    at Subscriber.next (http://localhost:8100/build/vendor.js:17840:18)
    at MapSubscriber._next (http://localhost:8100/build/vendor.js:51294:26)
    at MapSubscriber.Subscriber.next (http://localhost:8100/build/vendor.js:17840:18)
    at ReplaySubject._subscribe (http://localhost:8100/build/vendor.js:57666:24)
    at ReplaySubject.Observable._trySubscribe (http://localhost:8100/build/vendor.js:16977:25)
    at ReplaySubject.Subject._trySubscribe (http://localhost:8100/build/vendor.js:20819:51)
    at c (http://localhost:8100/build/polyfills.js:3:19752)
    at Object.reject (http://localhost:8100/build/polyfills.js:3:19174)
    at NavControllerBase._fireError (http://localhost:8100/build/vendor.js:54511:16)
    at NavControllerBase._failed (http://localhost:8100/build/vendor.js:54504:14)
    at http://localhost:8100/build/vendor.js:54551:59
    at t.invoke (http://localhost:8100/build/polyfills.js:3:14976)
    at Object.onInvoke (http://localhost:8100/build/vendor.js:4930:33)
    at t.invoke (http://localhost:8100/build/polyfills.js:3:14916)
    at r.run (http://localhost:8100/build/polyfills.js:3:10143)
    at http://localhost:8100/build/polyfills.js:3:20242

I am suspecting that it is the client, and not the server that wants to talk to the USB (?).

I've been grepping the code for why to specify a device name, but to no avail. I suspect that the "backend" code assumes that the serial connector of an Android device is attached to the CU rather than a Linux host that runs the server (?).

Any insight would be appreciated. Thank you.

[godmar]

ps: after studying your code a bit, I'm wondering if it would make sense to add a "remote-serial" backend. This backend would talk via TCP/IP (or more likely, via websockets/socket.io) to a server that proxies access to the actual serial device on a Linux machine to which the physical CU is connected.

This server could perform either low-level forwarding between the client and the actual CU, or it could be written with your carreralib library at the command level. In this way, ionic's serve ability could be used for a web-based version of openlap. I think even the "test" web-based version of openlap would make a great display fullscreen, visually more appealing than the built-in RMS in carreralib.

Given that you are the author of carreralib, this all seems a bit too obvious - is there something I'm missing? Some other software I'm not aware of that already does this?

BTW, I was really impressed with the demo included in openlap (and openlap overall, which seems to be a very solid piece of software).

[godmar]

Another idea: can we add browser as a platform for the Ionic app, then write a backend for chrome.serial, and bundle it as a Chrome extension?

[tkem]

The primary target for Open Lap is Cordova/Android. Chrome/WebBluetooth support has been integrated mainly to aid with development and as a technology showcase. Running this "natively" on Linux is definitely not supported, and will not work.

As support for other targets/platforms is of little interest to me, feel free to fork this and try your hand on it yourself, like @softyde did for iOS. If it's easy to merge, I'll see what I can do.

[godmar]

Thanks for your reply.

BTW, I was able to get the app from the PlayStore to (almost) work on a Android tablet with a USB cable. On issue is that in order to start a race, I have to first press the "Start" button in the app, which makes the five LEDs on the CU light up, but then I have to press the "Start" button on the actual physical CU before the race actually starts. Is this how it's supposed to be?

[tkem]

To start a race, you use the Menu -> Race dialog, I suppose? Then the startlights should light up automatically.

[godmar]

Yes, Menu -> Race. The "start" button is top-right. When I do that, all 5 LED on the CU light up, but the race doesn't start (that is, there's no power to the rails). Only if I press the "Start" button on the actual CU does the start countdown take place.

[godmar]

Your code seems to be calling toggleStart only once here which may have the effect of "pushing" the ENTER/START button once. On my track, you have to push the ENTER/START button twice before the race starts, however. Maybe I'm misreading this in your code, though, I'm not sure when the 'getStart' event fires.

FWIW, my manual doesn't actually describe how to use the ENTER/START button, so I'm not sure why it needs to be pushed twice.

On your track, how often do you need to push ENTER/START to start a race?

ps: I tried to google this. One thing I found was this video from 2013 where the person pushes ENTER/START twice as well. Is it possible that your code assumes a newer firmware version (?). Seems unlikely given how much experience you have.

[tkem]

From the README:

Some features, such as the start light and pace car buttons, will require Carrera® Control Unit firmware version 3.31 or higher.

So if you're running firmware version 3.30, control of the start light won't work. I'd suggest you get an AppConnect dongle and update your CU firmware using the original Carrera Race App. Otherwise, functionality will be limited. Period. If you don't want to do this for whatever reason, I'd recommend looking somewhere else. CockpitXP or Bruce Yingling's RMS might be more like what you're looking for.

[godmar]

Thx. I saw the README but didn't know what "start light" meant. I think having to push START is not a big deal.

I saw the softwares you mention but they do not appear to run on Linux and/or Android.

As much as adding support for remote serial and/or a chrome extension with local serial would be a fun project I think I may just get the AppConnect Bluetooth dongle. From what I've read it seems to be the only way to update the cu firmware also.

I could then use your app and screencast on a Roku connected to a TV.

[tkem]

Trust me - getting the AppConnect dongle is money well spent compared to the effort you'd have to put into this project ;-) It does have its flaws, though, especially with older and/or more exotic (cheap) Android devices. So the original intent for adding Serial support to the Android app was as a way to rule out any Bluetooth issues when debugging. So a serial cable connected to your Smartphone may be still be a viable alternative... OTOH, for a "native" Linux approach, carreralib may still serve as a basis - there is a at least one project that took the "demo" RMS a step further: https://github.com/Scummer/carrera-rms So maybe you want to dig into that, too.