Autosport Labs

psfp wrote:

mikesmith wrote:

psfp wrote:It was really simple (after I figured it out, of course )

I just added a "cursor = 1" row in Kivy's config.ini file

In which section? I've tried all of the obvious places, but I don't see "cursor = 1" mentioned in any of the relevant Kivy documentation (did you mean show_cursor?)

In modules section:


(to access this file you must type sudo nano /home/pi/.kivy/config.ini in command line)

Thanks - since one logs in as 'pi' the 'sudo' prefix isn't required.

Sadly, as Brent notes, things fall over pretty quickly when clicking around. Hopefully it's a bit more solid with the keybindings (I'm aiming to use the GPIO keyboard emulator to get some hard buttons).

need some help from you PI guys. I have a PI3 running stretch lite. ive installed the GPIO buttons according to THokes82 instructions. only difference i used pins 36-40. ive been working on it with the mouse and keyboard hooked up. works perfectly untill i unplug the mouse, then touchscreen fails to work,GPIO buttons work. plug mouse back in, reboot, GPIO buttons work fine, touchscreen works fine. so i would assume it is readdressing the /dev/events?

FYI, im not using the official screen.

it also now seems to take several seconds to connect to my MK2, is see a bunch of time outs in the log. but id like to address the mouse issue first. thanks dave

I was able to figure out the /dev/events addressing problem. fix was changing the config.ini input to "device_%(name)s = probesysfs,provider=hidinput". thanks google!

I do have a question with the rc.local script. when I add the script for the automatic startup, works good (RPI boots into RCP in less than 20 seconds). but when I exit the RCP app to get back to the terminal, it just reloads the app after a few seconds. not enuff time to kill the app process. is this normal? I would think the start up script is only called on startup.

PS14 wrote:I was able to figure out the /dev/events addressing problem. fix was changing the config.ini input to "device_%(name)s = probesysfs,provider=hidinput". thanks google!

I do have a question with the rc.local script. when I add the script for the automatic startup, works good (RPI boots into RCP in less than 20 seconds). but when I exit the RCP app to get back to the terminal, it just reloads the app after a few seconds. not enuff time to kill the app process. is this normal? I would think the start up script is only called on startup.

I don't have my Pi handy, but check to see which run level executes rc.local. I think it should be started in the RC3 level, but not positive.

mikesmith wrote: Sadly, as Brent notes, things fall over pretty quickly when clicking around. Hopefully it's a bit more solid with the keybindings (I'm aiming to use the GPIO keyboard emulator to get some hard buttons).

Just to update - things are looking much better with the 1.12 build.

You can still make it very sad with keybindings (S or A from the main screen in particular), but I got a Pi 3 in the meantime and the snappy level is also much improved.

Thanks for testing it! Glad the downloadable 1.12.0 package is working well for you.

I've been playing around with the SunFounder 10.1" capacitive touch screen this weekend and am pleased to report I have it working with the RaceCapture app on the Pi. I ended up doing it similar to PS14's way with the Waveshare resistive touch.

I edited /opt/racecapture/run_racecapture.sh and commented out everything involved with "check for ar1100 resistive touch" and "check for ft5406 capacitive touch".

Edit /home/pi/.kivy/config.ini and add these lines from ft5406 config file to the top:

[input]
mouse = mouse
mtdev_%(name)s = probesysfs,provider=mtdev
hid_%(name)s = probesysfs,provider=hidinput
%(name)s = probesysfs,provider=hidinput

[modules]
cursor=1

Everything seems to be working as needed. Just figured I'd give more info for another working touch screen.

I got my PI3 running with the standard 7" screen this morning in about 45 minutes the benefit of 20+ years of Linux experience. However RC app doesn't seem to be getting any data - the setup shows it's connected to USB but when I swipe to the "Raw Channels" screen I get "Waiting on Data" and occasionally in the top right of he RC app I get "Searching for /dev/ttyACMO"

Anyone know what the issue may be?

Hi,

What happens when you check dmesg and you plug RCP into USB? do you see any messages about /dev/ttyACM0 or similar?

If you do, try launching minicom, pointed to the device reported by dmesg. Are you able to see the console?

Also, What RCP hardware and firmware version are you running?

Hi Brent, a got it to work, I didn't do anything however. After about 4 or 5 minutes it connected and was solid. Not sure why it takes so long for the Pi to read the Race Capture.

I've upgraded(?) to a Waveshare 10" cap-touch LCD which emulates a HID mouse. Everything seems to "just work" with the default Kivy config... except that the mouse Y direction is inverted.

I found out how to invert touchscreen X/Y axes, but so far have had no joy talking Kivy into inverting the mouse (and honestly, why should it? this should 'just work')

Any thoughts on a Linux or Kivy-level config that will let me flip the Y axis? It's a bit of a brain teaser but otherwise seems to work very well...

Just wanted to share that I got this working with the following setup:

Raspberry Pi 3 B+
7" Official RPi Touchscreen
Raspbian Stretch Light

I had initially tried installing on the existing Jessie image I'd been running on the RPi, but that wasn't so successful. The app would load but basically hang immediately. Not sure if some of the configurations I'd done to set the RPi up as an APRS repeater (ham radio stuff) was messing with it, or if running the GUI and RCP at the same time was too much for it... but either way I just started from scratch with a new SD card.

One thing I did find after getting Stretch Light going was the WiFi setup instructions on the wiki didn't work for me. I think a simpler way to do this is just use raspi-config. That's what I did, worked great, then I was able to continue getting the installers.

Actually, here's a list of what can be configured by using "sudo raspi-config"

• - User password
  - Network Options
  • - SSID & Password
    - Wifi Country
  - Memory Split (Advanced Options)
  - Localisation Options
  • - Timezone
    - Locale (default seems to be US-GB (Great Britain)
  - SSH Access (Interface Options)

Might be a little easier for some of the newer Raspberry Pi users...

Anyway, I'm SUPER excited about this. The Android tablet approach never really left me 100% satisfied with the speed - I probably should have just bought a better tablet - but the RPi app seems to be zippy as hell!

Planning to get this set up in our LeMons racing Miata as the main dashboard since most of our stock gauges don't currently work. I found a 3D printable housing someone had put on Thingivers - https://www.thingiverse.com/thing:2252864 - that fits right into place of the old gauges! Now to find somewhere to print it......

EcotecMiata wrote:I got my PI3 running with the standard 7" screen this morning in about 45 minutes the benefit of 20+ years of Linux experience. However RC app doesn't seem to be getting any data - the setup shows it's connected to USB but when I swipe to the "Raw Channels" screen I get "Waiting on Data" and occasionally in the top right of he RC app I get "Searching for /dev/ttyACMO"

Anyone know what the issue may be?

I got my PI3 B+ up and running as well, but i see the same "Error Reading configuration..." / "Searching for /dev/ttyACMO" for about 5 minutes then it seems to stabilize and work. Is there something I should be change to get the syn correct to the race capture more quickly?

Hard to say without knowing more.

Does it still happen after repeated attempts? The app remembers the last port it successfully connected to.

Also, try checking with a factory default configuration (use minicom to issue the 'resetConfig' command at the CLI) and see if that still happens.

brentp wrote:Hard to say without knowing more.

Does it still happen after repeated attempts? The app remembers the last port it successfully connected to.

Also, try checking with a factory default configuration (use minicom to issue the 'resetConfig' command at the CLI) and see if that still happens.

So it looks like this issue is related to when the racecapture device doesn't have an satellite connection. Once the racecapture has 2 satellites locked onto, the Pi doesn't loose connection to the racecapture any longer.

Is this a bug/improvement that could be made in the error message on the screen?