Perhaps a silly question about automatic resume

[MoBe]

Hello, not sure I am in the right forum, if not, I would be happy to ask elsewhere.

I do not have a device, I will need to purchase several devices as part of an art installation. I'm hoping Rockbox would be the solution I'm looking for. This is what I need to happen:

1. The device will be connected to a solar charger 24/7
2. While on, it will loop a sound file
3. The power will be cut through interaction
4. When the power is re-connected, after whatever length of time, the device needs to automatically start playing, even if it was off.

Would the Rockbox "resume on startup" do this?

[gevaerts]

Rockbox can be configured to do exactly that, yes. You set the start screen to resume, and you set the playback mode to repeat, and tings should work.

I'm not exactly sure how you want stopping to work, but if you want a clean shutdown if power is cut, also enable "car adapter mode" which will pause playback when external power is cut (and restart when power appears again if the device happens to still be running), and set the idle poweroff setting to something fairly short, that should also work.

Also, don't forget you have the source, so anything is possible :)

[MoBe]

Thanks for the reply!

The device will be connected to a solar charger and a photocell "switch" so when it is dark (night/someone covers the photocell) the power supply will be cut from the player and it will stop playing.

My worry was that "startup" means that an "on" button has be clicked, since I don't have a device to test with, I wanted to make sure it would work completely hands free. Idle poweroff  wouldn't work since it has to work continuously unless the photocell reads "dark".

Having the source won't do me much good, I'm not too proficient at coding (or I'd probably opt for an arduino solution).

Thanks again, I'll have to see which player would work best and just make a decision.

[gevaerts]

For the power on, most players will do that just fine when power appears, but I'd recommend asking here first for the specific player you have in mind.

[MoBe]

Hi again.

Is there a forum you would recommend for me to ask for recommendations? Since each player will be playing one file, all I need is this autoplay function and a robust enough device, as it will be in a waterproof box, outdoors.

Another questions just popped up -
Can Rockbox recognise a power "event"? So that even if its battery is charged it would stop when power goes off and resume with re-powering?

Thank you!

[gevaerts]

Can Rockbox recognise a power "event"? So that even if its battery is charged it would stop when power goes off and resume with re-powering?

That's what car adapter mode does.

[MoBe]

Perfect, thank you so much!

[MoBe]

Can Rockbox recognise a power "event"? So that even if its battery is charged it would stop when power goes off and resume with re-powering?

That's what car adapter mode does.

I had a look in the Sansa Clip+ manual, under Car Adapter Mode, and it says: "Once the player is shut off either manually, or automatically with the Idle Poweroff function, it must be powered up manually to resume playback."

Does this not mean it has to be turned on manually to start working again? (sorry, as I said, not super techy).

[[Saint]]

Are you confident a digital audio player is the best fit here hardware wise?

I think one of the many cheap ARM development boards out there would be a better fit, with wider options for future projects. One board could also govern several installations and play multiple tracks simultaneously if need be. The cost would be around the same ballpark as well.


[Saint]

[MoBe]

Thank for the response.

I looked at the Arduino option, at the moment I prefer an audio player over a development board.

[[Saint]]

The reason(s) I suggest a cheap development board are as such:

1 - cost: A single board can run your entire project and is likely going to be appreciably cheaper than several digital audio players, even second hand ones. Even multiple boards (one per display) may well end up at the same price or less.
2 - reuse: a development board is going to see you through many projects, whereas a DAP is a DAP and its uses are understandably limited.
3 - limitations: a development board won't be bound by the limitations of the Rockbox playback engine (for example, you would be able to trivially play multiple tracks at once)
4 - hardware adaptation: you could quite literally just jam a couple of photocells directly on to the GPIO header.
5 - network stack: who doesn't like network stacks?
6 - scripting: reasonably self explanatory
...
And so on.

The only obvious downside is getting ones feet wet in scripting and embedded development.


[Saint]

[MoBe]

Hi [Saint],

Thanks again, I really appreciate the input. In the case of this project, most of the advantages are irrelevant (no network, not convenient running from one device, each will only run one file, and I won't be doing post-installation maintenance). The disadvantage of my current rustiness is important as I am pricing it also according to how long it should take to make.

Since it would be a funded project, I can't charge the commission for the equipment I'd need to even get started (decent soldering equipment, an arduino/other board etc.) and I can't afford good long-lasting of that at the moment.

Taking all those under consideration, I opted to avoid the development board option, unless nothing else works (if I even get the commission, who knows). Originally I didn't want to over-explain since I didn't think it would matter, but here, those were my (cowardly, insecure, but still mine) reasons.

I really do appreciate the time you took, and I totally see your point, it's just not the right opportunity for me to go there right now.

Thanks!