Page 7 of 16
Re: SD player UI development
Posted: Wed Apr 18, 2018 5:34 pm
by nige2000
randytsuch wrote: ↑Wed Apr 18, 2018 3:38 pm
Looking at the table on bottom of page 13 of Nige's link, looks like the flashair has three modes: SD, SPI and GPIO.
Since it only has 8 pins, the pins had different functions depending on what mode its in. Looks like you can send it commands to put it in different modes, but I'm not sure how this would be implemented on the SD Player card. I expect the SD player wants the flashair to always be a SD card, and won't be happy if it can't access the card because its in another mode.
So, IMHO, while this sounds cool, I think it's adding complexity by trying to add functions in the flashair card than can be implemented in an ESP card fairly simply.
Randy
how do we connect the esp to a controller/app?
thought that maybe we can pass through instruction via sd/spi/gpio
maybe im way off base here
ive no experience of such things unfortunately
Re: SD player UI development
Posted: Wed Apr 18, 2018 7:08 pm
by randytsuch
nige2000 wrote: ↑Wed Apr 18, 2018 5:34 pm
randytsuch wrote: ↑Wed Apr 18, 2018 3:38 pm
Looking at the table on bottom of page 13 of Nige's link, looks like the flashair has three modes: SD, SPI and GPIO.
Since it only has 8 pins, the pins had different functions depending on what mode its in. Looks like you can send it commands to put it in different modes, but I'm not sure how this would be implemented on the SD Player card. I expect the SD player wants the flashair to always be a SD card, and won't be happy if it can't access the card because its in another mode.
So, IMHO, while this sounds cool, I think it's adding complexity by trying to add functions in the flashair card than can be implemented in an ESP card fairly simply.
Randy
how do we connect the esp to a controller/app?
thought that maybe we can pass through instruction via sd/spi/gpio
maybe im way off base here
ive no experience of such things unfortunately
I've used ESP's for Home Automation/IOT type projects fairly recently.
I used ESPEasy
https://www.letscontrolit.com/wiki/index.php/ESPEasy
You program (via USB) an ESP board with ESP Easy, then it will come up as an access point. You connect your PC to this access point, then configure the ESP to connect to your wifi network.
After that, you reconnect to the ESP via normal wifi, and you can configure the ESP for various tasks. It supports a bunch of different IO boards.
For this, I think I can connect the ESP GPIO pins to a bunch of optocouplers, and then the optocouplers will control the switches.
Once the ESP is setup, you can send it commands over http. The most basic way to do this is to use a browser, so we will need to have a way to send http commands with our new software.
I have some instructions I did at the time I was working on this stuff, I'll check them to see if they still work, I just got a wemos d1 mini ESP board the other day and need to set it up.
Randy
Re: SD player UI development
Posted: Wed Apr 18, 2018 8:40 pm
by Fran
Good discovery work going on here lads, I'm following but with little time to contribute anything much.....
Re: SD player UI development
Posted: Wed Apr 18, 2018 8:48 pm
by jkeny
Randy, you're using optocouplers to stop noise bleeding from ESP to SDP ?
I agree using ESP devices is more functional than Flashair for IoT use - so getting some experience in this would open up the world of IoT for us - jeez, we could use a swarm of ESP devices with our audio equipment - think of all the audio multi-room interfaces we admire :)
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:15 pm
by nige2000
does that mean we use the esp as a router? that the flashair card connects to it via wifi?
so that we dont have to connect to flashair to upload then esp to control?
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:25 pm
by jkeny
nige2000 wrote: ↑Wed Apr 18, 2018 9:15 pm
does that mean we use the esp as a router? that the flashair card connects to it via wifi?
so that we dont have to connect to flashair to upload then esp to control?
AFAIK, I think at the moment we have to have two different WiFi channels - one to connect to Flashair for sending audio files to the card - the other channel communicates the button commands from the control device (PC or phone)?
Unless we can come up with a better plan, that seems the way to have the functionality that we need?
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:34 pm
by nige2000
Surely there's a way to do it one one network?
Still better than ir I think
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:40 pm
by jkeny
Nige & I seem to be the only ones with a SD player & Flashair card, ATM
There are a couple of things that have cropped up which we will have to address in our interface
When a file is uploaded via WiFi to the SD card in the player - it isn't visible to the ARM processor until a reset is done.
A reset can't happen in the middle of song playback so this has to be scheduled to happen when song ends
The problem this throws up is that if we are playing a song half way down in the playlist, a reset will reposition our current pointer to the start of the playlist.
One way around this would be to delete the song from the playlist once it is finished playing (& also do a reset) - that way we are always playing the first song in the playlist.
Another issue might be that the order of files on the SDP is not always the same as the control device - could be a problem with playback order or there might be a way to sort the display so the file list is in the same order on both?
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:42 pm
by jkeny
nige2000 wrote: ↑Wed Apr 18, 2018 9:34 pm
Surely there's a way to do it one one network?
Still better than ir I think
Hopefully there is but it may not be too much of an issue if the control program handles it all transparently - just a bit of a pain at setup
Re: SD player UI development
Posted: Wed Apr 18, 2018 9:50 pm
by randytsuch
John
Yes, I would add opto's to isolate the esp from the SDP. I'd imagine ESP's are noisy little suckers, so better to keep it isolated from the music player.
We could use relays too, but I looked at relays, and it takes more current to close a relay than I think it would take to drive the opto. Could add a transistor and stuff to drive a relay, but I have a bunch of opto's sitting in my junk drawing, so may was well use them lol.
Nige
In my scheme, the ESP is a router until you configure it with your wifi network name and password. Then you reset the ESP, and it connects to your wifi network. At that point, it's just another wifi client on your network.
So there will be two wifi interfaces:
1. Flashair card to write and delete music files and read the directory
2. ESP to send the commands, and simulate pushing buttons
I have a bunch of wifi interfaces at home these days, so a couple doesn't seem like a big deal. As long as we electrically isolate the ESP from the player, I don't think there is any disadvantage to adding this wifi interface.
One other potential use of the ESP would be to tap it into the display interface, to read what it being sent to the display. Then the software talking to the ESP could mirror the music player display.
I need to order a flashair, but I'll be out of town next week so likely won't do much on this until I return.
And even when I return I'll slow :) I also have Richard's DAC coming to me, and I will need to work on getting that going too.
Randy