-
• #76
-
• #77
Nice! Wow, there's a lot of stuff on that one board!
Slightly surprising seeing that big flash(?) chip on the back of the EasyVR board too!
-
• #78
Really nice :) Here is the datasheet on the parallell flash chip.
1MB would give only slightly more than 10 seconds with 16bit@44.1kHz, or twenty seconds if 8bit provides sufficient fidelity to catch the phonemes with the chosen microphone. Not too surprised to see a RAM on there :) When you have room to store the entire word instead of just a running buffer for the current phoneme you can make better predictions between words.HAve you tried it @DrAzzy ?
-
• #79
I've tested parts of it, but still don't have major pieces of the software together, and some of the wiring still needs to be done.
The indicator LEDs (WS2812's - I need indicators, but I can't spare the pins for normal LEDs) and I2C devices still need to be wired in. It's getting a BMP180 (maybe here I'll be able to make data come out of it?), color sensor (the good one, with I2C output, in DFN-6 package - why the chinese module people only make breakouts for the crappy ones with frequency output is a mystery to me). Chip on the bottom is an 24-series EEPROM (I thought I'd never get to use up those TSSOP EEPROMs!)
Yeah - it's a shame there isn't more memory on the EasyVR. I'd kill for more commands - it's capped at 32 total, I think due to memory limitations, which goes really fast.
Currently for testing, it's all powered off the USB (3.3v devices running off the Pico's regulator). When it's done, though, I'll remove the jumper, and connect the 3.3v regulator from the power section to the Vcc rail, and the 5v regulator on the bottom to the Espruino's BAT_IN (so that will be supplying the Pico, and the 5v RF comms board (this should be fine talking over serial, since the Pico's pins are 5v tolerant)
It also gets a keypad (connection point is under the wizio550), and that'll be mounted on a little piece of aluminum that will hide the top half of the device. Somewhere I need to fit a PIR motion sensor too.
The intended functionality is:
- Send RF commands in response to keypad, voice, or network commands
- Send HTTP requests to control the desk light and relay board based on voice commands. This may require modification of the desklight code, which is something which I always dread. It hasn't been updated since v72, since last time I did that, I lost most of a weekend debugging an intermittent caused by a damaged ribbon cable. Very very frustrating experience, not helped by the fact that I was working without sufficient light.
- Monitor motion, react with lighting as appropriate to save power and reduce summer thermal loading.
- Light color sensor to deduce whether the windows are open and what sort of lighting is in use.
- Monitor barometric pressure.
- Periodically poll a webserver to update it with sensor results, status of devices on network, and get any commands sent over the internet (this is polled, so nothing within my LAN ever needs to be exposed to the internet).
- Receive voice commands to control Fargo relays, desk light, and RF.
- Send RF commands in response to keypad, voice, or network commands
-
• #80
-
• #81
All the parts are on and basic hardware functionality checks out.
RF comms seems to be busted, but I suspect that's a problem with the software on the RF controller - need to take a look. That or I got the tx/rx backwards or something dumb like that. The TCS34725 works, and I submitted a pull request for the (very simple) module for it.
-
• #82
Great! Yes, I'll try and get that pulled in today :)
-
• #83
Thanks. Got the RF comms working mostly - that was a bug in AzzyRF which I've got sorted now.
-
• #84
However, what if there was a flexible protoboard that also includes
SOIC/SMC-compatible footprints, and that you could still trim to just
the area needed by your required components?A link to such for SOIC/SMS footprints in relation to nRF5X?