Search results for:

Had not seen this before the post here, interesting article for those who need an update :) Excellent that it mentions Espruino as well. I've tapped into - and ran a few open source projects, but this is my all time favorite and @Gordon is my hero ;)

FWIW I chose Espruino because of the clever low-memory 'from source parse' idea. Plus the fact that the source code is really easy to read and understand. On top of all this, the project is very open to contributions!

The only time I've ever had issues with 'not being 100% compatible' was when I tried to use a framework for functional programming that I've written. Espruino did not support Function.length at the time, so I added it and it got accepted and merged within 20 minutes! Crazy!

Idea dump:
Another easy project with multi-colors is to make a fake tv that flickers and fades light as a TV would.
Poor mans burglar deterrent, or otherwise faking someone watching TV. :)

Maybe play some tunes with the piezo (mario, zelda, tetris)? Makes me want to do a simple midi to Espruino converter.. hehe

Poor mans theremin, with the rangefinder and piezo.

A dice that uses LCD and vibration sensor, maybe configurable between D6 D8 D12 D20 ... DX?

IR scan/repeat project, that could record a stream of IR then play it back. http://www.espruino.com/Pico+Infrared

Something like a CPU gague using the stepper and a small node program using

var os = require('os');
console.log(os.cpus());

I'm new to this as well. As I've had to learn things quickly I've adopted this "workflow":

1. Make sure you can actually get the part you want to read up on. I recently almost ordered a PCB that relied on a part central to it's design (an SMD antenna) which was not available anywhere I looked.
   
2. Find reference designs with google (similar applications of a similar device to what you're trying to do)
   
3. Verify relevant electric properties (i.e what currents it can handle etc, the interesting parameters will vary from part to part) for you design
   
4. Look at the pin out explanations (for a mCU you'll want to check things like verifying it has support for the IO you need etc) to verify it supports what you need and expect
   
5. Look at the available packages it supports, and I also learned it's a good idea to verify it uses the most common pin layout for common parts (SOT-23 transistors for instance, some odd ball parts will not be in the common configuration)
   
6. Google everything you're unsure about, or ask a friend, or ask a forum - such as this one :) I'm sure I'll post many questions here.
   
   

For me, it's been really helpful to view reference designs and tutorials/explanations on youtube.

I also have more than one CAD installed in case I want to reference an open source project or something like that.

Last point I learned when doing my latest project was to try to find my exact part when I place the symbol in the schematic. For the aforementioned project, I drew the schematic first, then had to go over and figure out exact parts and values. Let me tell you - it was no fun.

I don't really agree with your suggestion about how to write and handle the music :)

I think the better way to think about it is that the piece is written in 16/16 (yes yes I know it's technically still 4/4 with 8th notes but I'm trying to get at the point that each note is actually both a note and a pause to get the staccato feel of the original).

By counting it in my head as 16/16 I think this would be correct:

var tune = "E   B C D   C B A   A C E   D C B     C D   E   C   A   A         D   F A   G F E     C E   D C B   B C D   E   C   A   A       ";

Which is a string of 128 characters for the 8 bar song (with 8 notes and 8 pauses in each bar = 8 * (8+8) == 128) I've not tested it but I think it should be close :)

Awesome stuff!
You should consider adding a mirrored mode, its crazy difficult!

(You see the the piece mirrored by horizontal/x axis. I did this for a clone i did as part of 1st year of my education and let me tell you - it takes a while to get used to it! When you get used to it, it's fun to swap back as well :D [I actually have a bachelors in games programming of all things...])

An update for the XLR summer box. I've made progress on the summing boxes themselves.
I've breadboarded a proof of concept of the schematic, and started a board layout based on this.

These boards will be the boxes that does the summing, controlled by Atmega168s. These boxes will in turn be controlled by another component that will simply be an espruino with an ESP8266 running as AP, and a serial bluetooth - in a project box.

This way, the audio engineer can use a wifi or BT enabled device to control the attenuation of each line on stage, before the sum is sent to the front of house desk and its preamp.

I will change most components to SMD. Also, I need to find a way to cascade stageboxes so that two of them can act as 15 to 1 summing box. I think I know how to handle this with a separate XLR out but it's not yet prototyped or tested in any way (I plan on simply passing the XLR out signal to another XLR connector before the output shunt resistor).
I'm also hugely lacking the power section of the project.

Do anyone have a good pointer for how to do a simple yet effective mains-> X volts power transformation?

EDIT: I'm tempted to drop the phantom power stuff. There already is effective solutions for 'injecting' phantom power to mics so I think I'll drop it all together. I would still need some diodes and decoupling caps for output though, in case the engineer enables phantom power (48v) from the console. How would I go about finding good values for these caps? Hmm...

RE: @allObjects I'll post a video of my dad playing the pedals as soon as I get it all set up. I'm not that often at my home town any more so I don't really know when we'll get together and set it up. But there will be a video when I do :)

Hey! Thanks for the reply and the kind words :)

The idea behind this build was to make it quick and cheap, so I opted for a PCB that I could fit with parts on hand. Buying parts is insanely expensive in Norway because of tax and shipping for import, or local purchase from a retailer that has a profit margin near infinity (ie, a couple of resistor ladders, a QFPN/SOIC atmega and parts would easily amount to $150). I have a weller station and use 2mm flat heads mostly. It does the job :) In retrospect I think I should've gone the route you propose with SMDs and then use parts from OPL. Next time I will :)

The board will definitly be Espruinoified. Seed is not assembling it. We just purchased a reflow oven and a hot air rework station. It will surely be a learning process first, but having the ability to produce protos and rework them in house should be well worth the time and money investment. I hope...
This board is kind of an IoT playground with access to sub 1GHz from the 430 and WiFi through the ESP8266.

Yes, I've mentioned Wice before I think. The site is still a bit meh but I don't have time for polishing that yet. It will be better with time, I promise. It's basically just a poster we send before meeting with potential clients.

Sadly I think I made the footprint for the SMD [ZX62-B-5PA(11)] one, without through hole lugs. I'll try epoxy then...
I do have a benefit in the fact that I'll be the only one handling these boards. So I'll just need to be careful :) Should be fine right (I'm not clumsy at all, promise!...)?

Just a quick update. I got the PCBs from Seeed and I must say I'm impressed by the results (even though it's a very simple 10mil/10mil through hole thing:

After 30 minutes of hacky soldering, I got to this:

Soon I'll write the simple firmare for it, then it's time for the actual work. Soldering each switch which are retrofitted to the pedals and making some kind of suitable box to hold the PCB.

---

I decided to go for Seeed for a proto run for the internal development board I'm making at my job. It will be interesting to see how they handle QFPN and 0603:

This is a dev board with STM32F103 (thought about going with the F4 but skipped that for now) and a TI CC430 with a 4x2 header for the ESP8266.
(PS: I swapped out the vertical micro usb for the same the Espruino uses. Seems less likely to snap off, and I'll copy the glue-gun-like blob to add a bit support)

These are actually the first two boards I've ever designed on my own. Feel free to shout out if you see something that screams at you. I'm here to learn :) I goofed up the orientation of my voltage reg for the organ pedals pcb, had to make my own footprint and neglected to add silkscreen outline. That's what you get for cutting corners... Lesson learned. I also forgot ground plane on top layer (I did place one on the bottom though).

Very nice!
ps: I like the black wires

Wow! Nice job @tage! That looks awesome :)

I am waiting for my new Rigol DS1054Z which I found after quite some research to be the best 'bang for the buck'. It's what eevblog recommends to (and general consensus on the forum over there too).

As for power supply, I have no idea. I'll follow this thread and hopefully someone has some good pointers.

I also like the 'general electronics' sub forum idea :)

I thought they were shutting down?
Do you have the source?
I'd really like there to be an RSS feed... (yes, I'm one of those guys)

I'll post some pictures when it's done :)
The PCB is designed and ordered from OSHPark, it's my first PCB that I've made on my own so that's exciting (I realized after pressing the upload that bottom overlay was not mirrored, I thought Altium fixed it for me... I sent them a support notice but they did not see it before it was too late, haha - it will be a token of my learning process)!
I need polyphony so I just gave up on being clever, and will wire each pedal from V+ to pin (they are pulled high).
Also, I had all the parts I needed as through hole so the entire thing is through hole construction. It looks really old school :) I'll post some photos later today :)

Not sure I could use the MCP4xxx I'll browse around when it's time to choose. I need ca 50K log dual wafer (not necessarily dual with control over both, I actually prefer not having to control both).
And indeed, the current design is to make each box have an input of 8 (kind of a standard in PA audio; 2,4,8,16,24,32) and they will use serial for linking. I imagine every box having a serial in (really duplex, but 'in' comes from either the host [computer/device] or the previous summer), and a serial out (that connects to the next serial in).
This way, the system could self assign IDs to each input and be uniquely addressable from the host.
I think I'll just use RJ11 for connecting between host and summers.

So, for 40 mics I'd use 4 summer boxes, and four long XLR running from scene to front of house, along an RJ11. Connect a simple FTDI thingy to my surface and assume 100% control of every line without the need for my good but old huge analog desk.

EDIT: If I'm successful I know a few people who would like this kind of thing (they do exist in some respects but are extremely expensive. I will of course open source everything, and I plan on using the Espruino as the brains. Updating then, could be as simple as plugging in the USB and run a small program based on the espruino-tools :) #nice!

Really I just wanted to post because I'm excited about receiving ten more Espruinos to add to the growing net of things at my office.

I can't really talk too much about this project because of stupid NDAs and such. Will probably update when we decide what should be open, what can be talked about and what should remain IP (as you probably guess, I am not the decision maker on this topic...).

I can talk about my side projects though:

MIDI pipe organ pedals
My dad is an organist, and currently he has to visit the local church in order to rehearse the often intricate bass lines on some of the pieces.
He inherited an organ when he was young, and he actually kept the pedals! So, I'm retrofitting switches and through the magic of Espruino and shift registers he can soon rehearse at home, with true pipe organ pedals :)

Remote Controlled XLR Summer
I run a side business as an audio engineer, and my current setup uses two multi-cable stage boxes. One of my recurring clients is a choir, with handheld microphones (that's 40 mics on stage!). Though, my current setup works, it is a pain because I need two mixers at the front of house in order to mix everything (my SI Compact only has 22 preamps).

I'm currently trying to understand enough to make a prototype with passive summing, and digital potentiometers to control each mic in the sum.
If there are anyone on here with experience that relate to analog audio summing then I'm more than happy to get a few pointers. I'll post some schematics and the like when I've got more than the good old off-the-cuff-pen-and-paper doodles.

For me, as I stated I got Bad Gateway and Internal Server Error. Sadly I don't remember if I got any content served from the apache. I checked with developer console and inspected http status code (I don't think I got served content).

The thing I do remember for this incident was that Espruino.com was still up even though the forum was down. This has happened about three times since new year, for me.

I had planned to try this band with a CC1101.
It talks standard SPI (I've done it with Wiring/Arduino - and I think SPI is much better implemented on the Espruino) and should be easy.
With that ship you can investigate other bands as well, and a few different operations.

Unfortunately I have not tested any modules for it, I bread-boarded one of the reference designs when I tried it.

---

I'm using this radio to implement DASH7 but because I will implement mesh network, I need more space to get a routing table and an A*/Dijkstra and ended up settling on having an CC430 coprocessor for the networking and encryption, at least for the prototyping stage. Maybe I can cram everything into the STM32F4 when time comes....

Let us know if you order some modules :)

Bad Gateway and the occasional Internal Server Error.
Glad it seems to be up and stable now :)

I guess it's most likely the voltage regulator that's producing the heat.
How do you power it?
Has something happened to it? F.ex if you accidentally shorted something when putting it down on a conductive surface, or other things of that nature?

You could offload the hashing to an external µCU maybe? Then talk to it via serial/i2c/whatever.

This is available in Espruino https://github.com/espruino/Espruino/tree/master/libs/hashlib
Reference: http://www.espruino.com/Reference#HASH
I thought you had to compile custom hardware but this line makes me wonder @Gordon..?

---

EDIT: a bit too quick to the keyboard there... This is SHA not AES, silly me.
For adding a new library, see this tutorial :)

@boneskull
RE npm leads to per-user fixes:
When a library is pulled down to local file system, and the user finds a bug - and the fix - it's very convenient to simply fix the problem locally. Of course this is a completely wrong approach but users tend to bend the rules. With the current way things work, the only way to fix a bug is to fix it for everyone. Which is good.

What scenario do you want to realize with an API?
What are you trying to do with the espruino-tools that you're having problems with?
I'm pulling it in with npm as such: dependencies: { "espruino-tools": "git+https://<token-from-github>:x-oauth-basic@github.com/espruino/espruino-tools.git" /*...*/ }

Then

var spawn = require('child_process').spawn;
var child = spawn('node', ['/path/to/espruino-tools/index.js', '-p', '/dev/ttyACM1', 'mycode.js']);

child.stdout.on('data', function(stream) {
  //look at result of espruino-tools
});

*This is written from memory on my windows disc, the code is on linux so may be something wrong. Let me know if you want me to post the real stuff...

You can't really debug it anyway, right, so why do you care what your
code looks like?

There's this http://www.espruino.com/Reference#l__global_edit :)

Some thoughts in random order:

Espruino IDE vs 'API':
You may get what you need from the espruino-tools project. I think it's unfair to compare the Web IDE to the Arduino IDE, which derives from Wiring which in turn is a fork of Processing. The Web IDE is much easier to extend and based on more modern and well documented technologies. I for one like it (even though I've ended up rarely using it, it's neat for demos and when trying out interfacing with new devices).
With the espruino-tools it is very easy to use practically any editor. I use sublime, brackets and atom with success.

NPM:
One concern with using npm (especially if npm install is not done each upload, which would then probably add some overhead in the time it takes to upload) would be that it kind of encourages quick fixes per user. With the current system, a user is more inclined to file a report, or fix the problem immediately.

Also, making npm available could quickly lead to a lot of questions about why things does not work etc. The Espruino is an embedded device with low memory and the interpreter does have some 'quirks' which a module author should know about and leverage/work around. Pulling in something 'simple' as _underscore will not probably be very successful.

"I make a small change to my code":
There's no such thing ;)
You should and would test the thing. So far I've had one such instance with the RFID module, it broke on my 1v72. The first thing I did was to upgrade to 1v74 (it was a module that had been running for a while) - and you guessed it. It worked!

In conclusion:
I think both approaches make sense. With the npm approach you put more responsibility on the user.
I imagine scenarios like this:
User reads a blog with a project that uses explicit versions (that's what bloggers are used to, because often the runtime itself can be upgraded with npm - so you can 'require' an identical setup). Then user copies code and config. Uploads but it does not work. Why? Because there's been an API change since the release and the Espruino running on the user's device is newer and incompatible.

Maybe the Espruino could be an npm module?
Maybe modules should alert the user if it's using a well known incompatible module/espruino version pair?

I don't mean to seem overly negative, I would probably like this feature - but I'm not convinced it's the right approach.
Npm shines for web because there are so many permutations of the javascript environment, but for the Espruino there's just one. Furthermore, the code that runs on the device should be written specifically for the device, so it's really not much argument about being able to pull in other npm modules.

My all too many bytes on the matter.

High quality manufacturer, beauty! (EEVBlog says it all the time 'bjuti', though - as you already pointed out - he says a lot of things during an episode...)

About testing manually, sounds like this could be a true 'stress test' of the espruino-tools?
I would love to see a video of how you test the Pico when you get a workflow up and running. Send me a paypal account and I'll give you some beers for it :)

While on that topic, do you have some sort of setup for donations? I accidentally missed out on the Kickstarter - but I want to be able to contribute to the project.

You're thinking along the lines that you will give the user a 'copy' of the relevant file in a markdown editor. Then when user saves, you get that file on your server somewhere - then diff it into the github?

Definitely a simpler solution than the table thingy I thought of. You could actually just use the same copy of the file until you merge as well (probably what you thought about doing).
A good idea about the FIXME: too, this way it's the same interface for contributing with the fix as it is with contributing with the 'needs work'. I like it.