Search results for:

Oh, I just found your problem!

E.getAnalogVRef() returns something that's nearly 0 on V53 of Espruino firmware.

 _____                 _ 
|   __|___ ___ ___ _ _|_|___ ___ 
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v53 Copyright 2014 G.Williams
>>
=undefined
>E.getAnalogVRef();
=0.000050167224080267551

OH! I missed the part about powering only VCC off the +3.3 - I thought you had connected both the VCC and VDD to +3.3. That all makes sense then - and the separate powersupply obviates the need for the bypass cap.

That actually gives the WS2812 a benefit over WS2812B, since you can run a separate VCC line for the WS2812 and skip the individual caps, and just put one big one at the end of the string to keep VCC in general up...

Around -20C by any chance? (in other words, tempinc=(-0.4)*tCooef, so Vout=0 because of a wiring issue or something like that)

I get why there are two three wire plugs... but what's the pair of wires coming out? Just for connecting higher current power supply?
Edit: On the WS2811, it's possible to separate the power supply for the LEDs from that for the control circuitry - that's probably what's being done here.

Reversing Dout and Din doesn't kill anything (it just won't work), so as long as you get the +5v / Gnd right, you can try both ends for data. But you do need to be damned sure which is +5 and which is ground, the WS2811/2812 (but not 2812B) are notorious for dying if you put reverse voltage on them.

Pin strips are wonderful - you'll also want the connectors for it. These are (at least by some vendors) called dupont connectors. I bought a whole set of 1~9 pin housings and hundreds of female pins, plus some pre-pinned dupont line (the stuff with no pin housings on it)... For more basic needs, these ( http://www.ebay.com/itm/40PCS-Dupont-wire-20cm-cable-Line-color-1p-1p-pin-connector-/260980054045?pt=LH_DefaultDomain_0&hash=item3cc39f981d ) for connecting pins to pins, or these ( http://www.ebay.com/itm/40PCS-Dupont-Wire-Color-Jumper-Cabl-2-54mm-1P-1P-Male-Female-20cm-/251178082666?pt=LH_DefaultDomain_0&hash=item3a7b61616a ) for working with breadboards (they end in a pin on one end, though you can barely see in the picture). That ebay seller's entire store is full of cheap wonders (his stuff usually makes it to the USA within 2 weeks or so, despite the much more pessimistic ship times given, not sure about the UK) - so I recommend looking through the other categories of items too... unless you're on a budget, that is - it's mighty easy to nickle-and-dime yourself to death there (I think i've given them close to $200 in the past month or so, just getting "Oh that looks cool, maybe I could use a such-and-such sensor for something, and it's so cheap" kinda purchases and they don't even sell the good LEDs!).

Breadboards, I would recommend using only if you're really desperate, after you've broken up your furniture for fuel, and there's nothing else to throw in the fireplace to keep warm... But seriously, they're unreliable as shit, avoid them if possible (particularly if they're not new - they age poorly). I used them for a while, and I was spending more time trying to track down problems that turned out to be loose connections than I was on any other part of the project. And just the other week I sat around for a demo for like 10 mins while my friend redid a bunch of soldering assuming he'd burned out a part, only to find that nope, everything was fine, the breadboard just wasn't making good contact....

+Kalus - have you studied the datasheet (or what passes for one) for the WS2812? http://www.adafruit.com/datasheets/WS2812.pdf

Note particularly the app notes at the end, where we see the critical bypass capacitor (and resistor - though you may not need this), cryptically marked "104", ie, 0.1uf. The point here is to ensure that a high enough voltage remains on VCC to keep the control circuitry alive when it turns on the LEDs, and VDD momentarily drops in response to the sudden increase in current (due to the inductance of the wires). So they put a bypass cap between VCC and ground to filter this effect out, and charge it through a resistor for good measure.

On the WS2812B, they did away with the separate pins for VCC and VDD, and simply put the capacitor between the VCC and Gnd. This makes me think that one could probably get away with omitting the resistor between VDD and VCC on the WS2812 as well.

Maybe in your case the LEDs, running at a lower voltage than intended (I think - there's no spec in the datasheet for VCC/VDD, other than the absolute maximum), are thus drawing less current - enough that the momentary voltage drop isn't resetting it - and that's why it's working at 3.3 - although it's not going to glow as brightly. Do the blues look okay running at 3.3v? That should be the first color to suffer at low voltage. Also, as +Gordon said, you can only run like 2 WS2812's off of the Espruino's +3.3v supply (they're rated at 60ma each full brightness).

That bypass cap IS a real pain if you're hand-wiring up naked WS2812's (which I'm doing as well...)

My WS2812's seem to be working okay too on new firmware.

Are you using a bare WS2812, as opposed to one included as part of a matrix or on a breakout board? If you're using a bare WS2812, did you remember the 0.1uf bypass capacitor? Without that, the WS2812 will turn itself off if you try to light it with a bright color (the exact point at which this happens depends on the physical parameters of your setup).

The web IDE gets unhappy if you ever reboot or unplug the espruino while it's connected via USB - once in this state, you must exit the web IDE as well as all instances of google chrome and restart web IDE to make it work again. Could this have been the problem?

Yup - I'd have never figured that var foo=this; bit out on my own.

I think it would be nice to have an example of non-modulized code, and then the same code, in the form of a module, as part of the Module Writing tutorial. Some people (myself included) learn much better with an "example problem" so to speak.

I'm excited to submit a module. I can't wait to get some other sensor in the mail that we have no module for yet :-P

Has anyone had any success getting a WIZ550IO shipped to them in the US?

Shopwiznet.com was out of stock last week, then it was down at the start of this week, now they say they have it in stock, but the order process fails at the last step. And the bastards only ship via fedex - Ten bucks on a $18 item! Seriously, I don't know how Fedex/UPS can quote their prices while keeping a straight face, when I can get individual items shipped literally from the opposite side of the world for $0.89 with shipping included - but that's a different matter)

There seem to be no other vendors except one that wants me to buy 40 (and at almost no discount - if they were cheaper in lots of 40, i'd have half a mind to buy a lot of 40 and try to flip em on ebay)...

Edit: Their website finally seems to work, and I've got my WIZ550IO on the way...

I've got this working as a module now. Will issue pull request shortly.

Thanks for that bit of conversion into module-style code - not only does it now work as a module, I think I now understand how to make my code into modules in the future.

There exist charging only cables, and these look just like normal cables, and are never marked. They come with devices that use usb for charging, and we then put the booby-trapped cables in with our normal ones, assuming they're the same.
I've also seen (a disturbing number of) usb cables where the+5 and ground wires had ~3 ohm resistance - call it a data only cable....

And that's before considering possible damage to the cable.

I understand that talking about how how to write the code to control or do something with the Espruino and an external device is clearly on topic for these forums.

What about, however... general discussion about an external devices that one would control using a microcontroller? Would this sort of thing be considered off topic here? What forum would you all reccommend for this? As you might guess, I'm new to microcontrollers - writing C had scared me off before, so I don't really know what the go-to forum is for microcontroller discussion.

Thanks

That should work - though I'm not sure it'll be necessary to put the scripts onto the SD card, I can certainly see the utility of this.

No matter what, though, you should load the files onto the SD card using an SD card reader, and then put into the Espruino.
Using the Espruino, instead of a SD card reader (which can be had for about the cost of a latte, even in a brick-and-mortar store) to fill the SD card with static files from your computer would be a case study in how to make life hard on yourself. You can of course have your code write to the SD card, and send it code to write the files, but this is an awkward way to do it.

Regarding the original question - it should definitely support cards up to 32GB (the limit of the SDHC standard) if it supports cards larger than 4GB (the limit of normal SD), and I think as long as it's formatted FAT32, you should be able to go higher. Note that (as Gordon has said numerous times), Espruino only supports FAT32. Windows insists on formatting cards above 32GB (and such cards are typically preformatted) in exFAT, which presumably won't work. Google can tell you how to format them as FAT32 - there's oodles of information on this because some cellphones insist on FAT32 as well.

Is there a way to determine when this has failed, so, we could, for example, automatically retry writing it?

I will run into this issue pretty soon in my project. I need to be able to make sure that the data I'm logging is being recorded.

Define function onInit(), and put the code that needs to run on startup into that.

I think the problem with supporting HTTPS is that you need to be able to handle SSL encryption. There is an open source SSL library for embedded platforms, MatrixSSL that was mentioned in one discussion, but I'm not sure if even that will fit into the RAM available to the Espruino.

Excited to hear about the WIZ550IO support. Hope to order one soon - they currently seem to be out of stock at one of the few vendors selling them.

My understanding was that doing the crypto required for HTTPS is beyond the capability of relatively low power microcontrollers like the one in the Espruino. Is this accurate?

I would also be very interested in support for a wired ethernet adapter. I have one project for the Espruino that will definitely need WiFi, but most of my projects would be fine with wired ethernet, and wired ethernet is just so much more reliable. WiFi is only barely acceptable on a proper computer or mobile device (don't get me started)...

Is there a way to make the Espruino not clear all watches and timeouts when something errors out?

Aaah, okay, that would explain it!

Thanks

This looks much better:

var dht={};
var watch;
var i=0;
var out=0;
var pstart=0;
var badbits=0;
dht.read = function (a,pin) {
	dht.onreadf=a;
	if (pin===undefined) {pin=C6;}
	i=0;
	out=0;
	badbits=0;
	digitalPulse(pin,1,0.08);
	setTimeout(function() {pinMode(pin,'input_pullup');watch=setWatch(function(t) {dht.onwatch(t);},pin,{repeat:true});},0.07);
	setTimeout(function() {dht.onread(dht.endRead());},50);
}
dht.onread= function(d) {
	if (d.temp==-1) {
		dht.read(dht.onreadf);
	} else {
		dht.onreadf(d);
	}
}
dht.onwatch = function(t) {
	if (t.state) {
		pstart=t.time
	} else {
		var tt=t.time-pstart;
		if (tt < 0.000044) {
			badbits = 1;
		}
		if (badbits) {
			out=(out<<1) | ((tt > 0.000044) && (tt < 0.0001));
		}
		i++;
	}
}
dht.endRead = function() {
	clearWatch(watch);
	if (badbits && i > 32) {
		rh=(out>>(i-10))&0xFF;
		temp=(out>>(i-26))&0xFF;
		return {"temp":temp,"rh":rh};
	} else {
		return {temp:-1,rh:-1};
	}
}

Any other cleanup suggestions?

Aaah, cool - that's a neat idea, I hadn't really thought about making that sort of thing on the Espruino. Good luck!

Is the brewery within wifi range?
Using a CC3000, and having it post the data by periodically connecting and firing off an HTTP request containing the data might make the computer side of it easier. Wouldn't do any favors for the battery life (WiFi draws a fair amount of current, though you can and should keep it turned off most of the time).
I'd rather write a PHP/etc script to extract the data from the request than figure out how to get an obscure piece of network hardware meant for comparatively primitive systems working on any desktop computer, let alone linux....

Since it's a stationary installation, you don't even need lipo batteries... 3 or 4 NiMH AA's would be fine (careful with input voltage to CC30oo), and would have the advantage of being cheap to replace, chargeable with normal battery chargers, and alkalines could be used in a pinch (the beer must flow!).Whether this would be cheaper, I don't know. Remember, since there's no mains, you'll need at least two sets of batteries to keep this running. And maybe a juicy cap across the batteries so it doesn't reset when you swap the batteries...

I'd guess that it's not implemented yet. Lots of things aren't 100% done on the Espruino.

What's your use case, if you don't mind me asking? SD cards are just so massive compared to the amounts of data the Espruino works with (5 orders of magnitude larger), I have to wonder what you're doing where you'd have a desire to delete files.

Have you read this thread, particularly the bit about PDU encoding? http://forum.espruino.com/conversations/626/#comment7811

I know most of the modules for the Espruino are located at espruino.com/modules

But this doesn't seem to have all modules, including CC3000 as well as the other http-related ones. These modules clearly exist, though... Where are they? Where does the IDE look for modules, anyway? The documentation ( http://www.espruino.com/Modules ) doesn't specify where the modules get pulled from (beyond "online"), and it really ought to.

Thanks. Yeah, setTimeout() definitely works with values less than 1 ms, though I'm sure the timing isn't perfect.

Even if I were to setWatch() before the pulse, wouldn't I still need to do pinMode() after the pulse to set it back to 'input_pullup'? I'm already discarding some of the bits at the beginning (namely, the first two, from the handshake).

This delay is not the cause of the missing checksum bits, in any event - the missing bits should be at the end, while an incorrect delay would chop off the beginning.

Oh! I didn't realize you could access the variables from a function defined in setTimeout/setWatch - that makes life a lot easier.

I'll look into the bitwise operators - they're something I'd never really known existed, since I approach javascript from web development. These aren't used much in web design (for example, W3S doesn't even cover them). This looks so much more graceful than what I was doing.