The position tower functions properly in races managed by the Carrera app, but not in races managed by SmartRace. I've used the Carrera app on a Nexus 6 and Nexus 10, both on Android 5.1.1. I've used SmartRace on the same Nexus 10.
I'm not sure how closely this relates to the first (closed) issue regarding the tower, as I am not suggesting necessarily that SmartRace should control the tower like some other system does. I'm just disappointed that the tower doesn't work - it freezes as if the race was stopped.
I am willing to help you diagnose and test, if it will help.
I think you're right. Currently it's hard for me to find the time to do some debugging on this, but I will look into it again and try to make sure the tower is working correctly.
Hi,
I have a similar issue with the tower. As far as I am aware the tower indicates the positions correctly, but the number of laps is not shown.
Sorry, I checked it again yesterday. Seems that the tower is also not showing the positions correctly.
AFAIK, as soon as a Bluetooth or serial (PC unit) client connects to the CU, the CU does no longer update the lap counter automatically. This is now the responsibility of the app/PC-Unit, which probably should also update the cars's positions during a race. I guess this is by design, since the app/PC-Unit is "in control" of the race; this also allows counting down laps towards zero, as done by the Carrera app when going over a set number of laps. Slotbaer has the commands covered. I verified this also with my own Python implementation (
https://github.com/tkem/carreralib).
Ah, this is indeed very helpful! Nice, thanks a lot. I will have a look at your implementation. What I struggle with is to tell the tower how many laps a race is going to run (or how many minutes). I didn't yet manage to get that working. Also, I managed to send the right command to update the leader laps, but sometimes it seems to be just wrong. I didn't yet find out whats the issue there. Thankful about every bit of help :)
Well, I'm afraid there isn't that much to look at for now (initial commit was this afternoon). Just did a little RMS prototype that keeps track of laps for each car and sends max(laps) to CU if that changes. Seems to work, but didn't do much testing.
If I can be of any help with this, please feel free to contact me (tkemmer@computer.org). I'd *love* to see this working in Smartrace!
Update: Having done some more work on my Python implementation this weekend, it looks like it is sufficient to set the current (maximum) lap for the position tower - it will keep track of driver positions during the race by itself (at least for the first 250 laps or so)! So, this seems actually to be quite easy to do... Simply reset the position tower (J60910) at the start of a race, and then send the lap to be displayed using commands 17 and 18 (high nibble first!).
Thanks for this helpful advice, Thomas! I was actually able to get the position tower running tonight with some small code changes - yay! Will be in 1.3.2 :-)
Awesome news! I'll be off for summer holidays starting next week, so I sincerely hope v1.3.2 arrives before the weekend ;-)
Thanks for your efforts!
Hi Marc,
upgraded to v1.3.2, but I'm not sure it behaves like expected.
As far as I can see, the position tower's laps/positions now get reset at the start; so that's fine now.
However, I don't see the laps always being counted correctly. Mostly, the lap count at the position tower just stays at "0".
I managed to get laps counted *once* (don't ask me exactly how), but somehow some laps were skipped; e.g. position tower counted 0, 1, 3, 4, ... with lap #2 being ignored (position tower stayed at "1" until next lap).
Hm, thats very strange. It worked perfectly fine in all my tests, even with a lot of cars on the track. Where there any more oddities when you experienced this? Or is everything else working fine?
OK, I guess I figured it out - looks like v1.3.2 only sets the position in *lap-based* races. I was doing mostly *time-base* races (e.g. 5 minutes) yesterday, and then the position tower lap stays at zero. May I kindly suggest that the position is also set for time-based races, since it's also of interest how many laps have been driven so far?
However, even with lap-based races, there seem to be some minor problems left, since as I notices before, the position tower does not update regularly. Sometimes one lap will be skipped, sometimes two. Note that the final position is okay, it just looks like the command to set the position is sometimes never sent or received. Since I don't have that problem with my own "carreralib" implementation, maybe there is still some race condition (pun intendend) in the code...
race condition... :-D
Anyway, you're right, I will add the position tower support also for time based races.
Regarding the issues with skipped laps: I could see that in a very early stage of the implementation, but not in the final one. In your own lib, do you also poll the CU for data on a regular basis (like every 100 ms or so)? Or do you just set the laps on the tower to see if that works correctly? I would think that the hase is laying in the pfeffer somewhere around this, if you know what I mean. I will try to reproduce this on my own, too.
How is 1.3.2 for you in general? Are you happy with the changes and the overall stability?
Marc
Hi Marc,
with my own implementation, I just poll the CU non-stop, meaning I send a '?' command, wait for the response, send the next command, and so on. My own experiments showed me that *not* waiting for a response (with proper timeout, of course) may lead to "interesting" effects, but that may also be an effect of the underlying Python Bluetooth package I'm using.
However, I couldn't see this behavior (skipped laps) with the original Carrera app, either; but as we all know, that has some other issues of its own, otherwise we'd spend our spare time on something else ;-)
Apart from the skipped laps (which is actually a minor issue, since it "catches up" after some time) and the slightly confusing behavior with time-based races, I'm perfectly happy with v1.3.2. Great job! 5 stars ;-)
BTW, I'll be off for the next three weeks or so, but I can take a deeper look at this when I come back from holidays; checking the Android Bluetooth HCI-Snoop-Protocol to see if position commands are actually sent comes to mind.
Thanks Thomas, Ill also be on vacation for some days and try to investigate more on this afterwards. enjoy your time off!
A possible explanatiin for this behavior would indeed be a race condition, for example if you poll the CU via a '?' command and then send the commands for updating the position tower before the CU has answered the '?' command. I don't know how your app handles communication, of course, so this is a wild guess. But polling on regular intervals (100ms) via a timer and sending commands asynchronously without proper synchronization may indeed lead to this.
Added support for position tower updates for time-based races. I will continue to investigate the updating issue in a separate entry soon.
You need to be logged in to add a comment.