I’ve wondered why my trips are not fully recorded and noticed the “start-up sound” is played some time after starting the engine so I measured the time from starting the engine until that sound (which I assume to be the “device-ready” signal) and noticed the lowest time to be around 127s and up to not playing the sound within 300s after which my trip ended.
Most of the time the time span was around 127-160s.
Is this intended to be that high?
Are there plans to reduce this time (possibly through running all the time with lowest possible power consumption)?
I didn’t file this as Troubleshooting as my own car-entertainment-PI (which in the meantime got deprecated and re-used in another project) had similar boot times and I found no solution for this. On the other hand side previously I’ve used a proprietary dongle by a German company (not containing a PI) which instantly started recording the trip.
I came to this post because I wanted to know what the odd sounding “bleup” sound was for. I had also assumed it was an “on-line and active” sound, but again sometimes it can be minutes after turning the engine on. It is generally made sometime after I have started my journey and so I would suggest that a fix is necessary. Thanks.
Yes, we are working on ways to lower the startup time.
The sound is playing as one of the very last things, so most systems on the device is already up and running at the point of the sound.
We have also made changes that should make it log positions much faster.
So yeah, this is something we are working on improving heavily, but as this is a linux machine, it will never get to zero, but we should be able to improve the time before ready, and more importantly, the time before first position (time to first fix we can’t do much about, but we can make sure that the boot time is not the bottleneck).
We are very open to ideas and suggestions, and if you, by any chance, end up doing any development on this, and want to share your findings, please don’t hesitate
I would also give some feedback specially for the start-up time. I was using my Autopi since yesterday and i am very impressed about the autopi. The only thing is the start-up time. Today i was already driving since 12 min till the first record started. Is there any possibility to debug why? Furthermore, i am wondering about the start-up sound, because since my 3 drives i never heard this sound and it would be very helpful.
Yes, you can absolutely see what is going on, it should boot much much faster.
There are a few different ways to debug this.
Events
Check the events section on my.autopi.io, those events are triggered from the device, and by comparing the time that you know you drove the car, with the events, you can see if it has started, and maybe what events occurred late. It should have en engine/started event when you started the car. If it doesn’t you should check the logs to see what happened that may have prevented that event from being triggered, or sent.
Log files
You can either SSH into the device, and look at the log file: /var/log/salt/minion - or one of the other log files in the salt directory.
The other way, is to use the helper commands in the terminal, either in the online terminal, or in the local terminal.
Cool! - We have done some improvements to the boot up time, but there are still very much room for improvement.
What are your experiences applying it on your karaokepi? - that’s a zero too right?
If you happen to try some of them out on the autopi, we’d love to hear about it.
Yes the Karaokepi project is running a zero. Here are the improvements I got from my other project. I need to find a good weekend to try these on the autopi.
I had some of the tweaks applied and was doing around:
Startup finished in 1.646s (kernel) + 22.975s (userspace) = 24.622s
After applying all the tweaks without the recompiling kernel part.
Startup finished in 1.674s (kernel) + 21.238s (userspace) = 22.912s
But the biggest win was something that was not on that tutorial, it switching from Debian Networking to systemd-networkd.
Startup finished in 1.566s (kernel) + 16.380s (userspace) = 17.947s
I am new here, still waiting to install Autopi dongle to my car. It is allready at home.
I read this topic and was thinking if you could make start Autopi with opening the car by remote key. It would shorten the time by approx 8s (distance to the car, time to sit and time to start the engine).
Will it be possible?
Finding a way to somehow give the device a headstart is very interesting, but i’m not sure it’s possible to trigger the startup when unlocked, as the device would need to somehow need to be notified of the unlock event, which could be read from the CAN bus, but to read from the CAN bus, it will need to be awake.
We have other similar ideas, like being able to set a schedule for the device to wake up automatically, like if you use the car all weekdays to drive to and from work, it could start every morning and every afternoon.
We are working on making it possible to use the accelerometer to wake up the device, as that could give the device a few seconds headstart when the user opens/closes the car door (the accelerometer could also be useful in other situations, like if your car is hit while parked)
We continually work to decrease the startup time for the device.
I am new to this but really looking forward what would be possible to do with Autopi. Important info is that it could not read CAN till the Zero is running. I did not know it. What kind of input trigger can wake up the Zero through the Autopi? What is able to do Autopi without the Zero? Do you have any diagram of your Autopi board?
I was also thinking, if the Zero could run full time? How much power would it need? Would it be able to have its own battery to stay running during the parking time and just charge the battery during driving time? Could you run Zero in some sort of energy saving mode?
The reason I was thinking abaout full time working mode is that, I would like to use it for alarm trigger to run the camera immediately and to send some photos.
Currently it is configured to wake when the car starts (voltage change 0.2 volts over 2 seconds)
But it can also be woken by a text message, and we are working on enabling wake from accelerometer - but this is not yet released.
As the raspberry pi is the brain of the system, there is not much it can do without it - so running it full time could be an option - we are looking into this atm.
We are also working on a change to the system that will expose a lot of deep configuration parameters, that you can change from my.autopi.io - including sleep settings.
Some people use a raspberry pi 3 instead of the zero, as the pi 3 is much faster, it will also boot much faster - so that is also an option, but it will ofc never be as fast as a zero that is already running…
If you do more research regarding how this can work on the rpi, feel free to keep us in the loop
Thanks
Hi Malte, nice ideas!
They are all very welcome
Here are my 2 cents: it would be nice to have some trigger in the cloud dashboard to wake up the dongle. As far as i’m informed, the dongle goes to sleep after 30minutes by default, and pitily it’s not enought time till i get home and get to the PC, by that time the car is already offline…
i know, you could set it to stay longer on idle, but isn’t it nicer to be able to start it from the cloud? And this alos might be a solution to preboot before the driving starts (e.g. IFTTT, Amazon Dash hack, etc )
Adding this on here, a while back when I was walking up to my car and I unlocked the doors (I have a 1999 Honda Civic EX), I noticed it began booting up.
So it does appear possible to get a headstart on booting.
Hi! I’m trying to plan out a DYI security system using the AutoPi. And having the accelerometer trigger waking up the device would be golden. Is this functionality available now?
The functionality is there is the AutoPi Core, you just cannot control it yet from the Cloud. We are working on expanding this functionality and hope to have it in one of the next releases.
