Powering a lot of WS2812B LEDs from a 12V car battery - try this!

Ok so let's say you need to power a shit-load of WS2812B LED strips from e.g. a car battery.
You need to convert ~12v to 5v and you need a lot of current.
You also want high efficiency, and you'd like to be able to power them down completely to avoid the ~1ma-per-led quiescent current..

While perusing buck converters, I came across this, and was immediately curious... It's about $10 a pop.

http://www.prodctodc.com/dc-1014v-to-255v-15a-buck-converter-peak-20a-high-current-power-supply-p-121.html
also on Ali-express
http://www.aliexpress.com/item/5-PCS-LOT-DC-Buck-Converter-15A-10-14V-to-2-5-5V-Peak-20A-High/558859436.html

Rated at 20Amps, ideal for a large car/deep cycle lead-acid battery.

Seems like rather a fancy module on there, no? Well.. it sure is!

Eyeballing the part number it's actually a really high quality DC-DC converter module; the Artesyn "SIL40c-12sADJ-VS", now obsolete.
http://www.artesyn.com/power/assets/lf_sil40c_1208906885_techref.pdf

The module is actually rated at 40A continuous output with 92% efficiency, low ripple, and all the bells and whistles you could want.   Datasheet mentions 18.5A input (@12v) = 222W in and 40A @5V = 200W out, which is 90%, so only about 20W dissipation at full power.  Very nice.  Spec-wise this is far superior to all the other cheapo DC-DC buck converters from china, and a very good price at that.
The modules also support 'current sharing' as well as remote on/off, it's also _very_ well regulated to handle very rapid surges in current (i.e. all your LEDs going from off to on!), and so on.

Quite possibly by just beefing up the PCB traces a little with some thick wire one could get high efficiency car battery->5v @ 40A very inexpensively (about $10 a pop).

Looks very promising!

Caveat: It's possible the modules they're using are rejects but we'll see. They may just available b/c the module's been discontinued.

The three chips on the underside of the host board are a slight mystery; the two on the left look like reverse-polarity protection diodes on the input [update: no, they're P-FETs, only 2mv drop!]  (which I plan to bypass, not wasting my precious juice on them), the other in the middle... not sure yet [update: LM393 comparitor]  The module datasheet implies it's basically ready-to-rock as it comes, with only external smoothing caps.

Note that the module sheet suggests 2000uf output caps for 5v and these have only about 1200-ish, but should be ok.

I'll give more feedback when mine arrive... Excited!

UPDATE 1: DOH! The no-load current is like 290ma @12v!!!! WTF!? Gets toasty just doing nothing. Not so impressed any more. Also at 1.8A output I measured 1A/12.5V in = only 72% efficient. 

UPDATE 2:  Ok so the specs do mention the high quiescent current if you look closely, and if you can live with that the modules work very well; the load regulation is excellent.  It turns out the module does happily output well over 20A (tested at 30A - active cooling a good idea, the small heatsink gets literally hot enough to boil water; thermal cutoff is at about 120C(!) ) - however - the board the module is mounted on has a P-FET for reverse voltage protection on the input and that blows up (quite spectacularly; lets the magic smoke out) above about 15A input current. If you don't care about the protection you can bypass the fet with some (very) thick wire from the input terminals to the module and it works well at very high currents.

Overall it's a pretty good module as long as you're ok with max 13.8v input and wasting a fair bit of power as heat...

Wireless router dropping connection under load - dmesg shows "ath: phy0: Failed to stop TX DMA, queues=0x004!"

Symptom:
Atheros-chipset based router, specifically:

Router Model

Buffalo WZR-HP-G300NH

Firmware Version

DD-WRT v24-sp2 (05/27/13) std - build 21676

Kernel Version

Linux 3.9.4 #320 Mon May 27 02:09:45 CEST 2013 mips

Was dropping wireless connection to my Nexus 7 (and iPod touch) when downloading anything large, e.g. app updates.

Connection would drop on client, interrupting whatever was downloading, then few seconds later would reconnect and continue, then drop again, etc.

dmesg from shell on the router gave me:

ath: phy0: Failed to stop TX DMA, queues=0x004!

every time it dropped the connection. 

cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset

    Baseband Hang: 2538

Baseband Watchdog:  0

   Fatal HW Error:  0

      TX HW error:  0

     TX Path Hang:  0

      PLL RX Hang:  0

        MCI Reset:  0

REALLY ANNOYING.  Lots of internet sleuthing later, I appear to have found a fix!

TL;DR - TRY THIS

Make sure you're not using WPA2/ TKIP mode! Use AES instead - do not use TKIP.

Simply switching from TKIP to AES made the problem disappear completely. 

SO happy about that.

Work for you? Comment below please :-)

Djangoh-my-goodness

Django is good, now I go kick the tires a bit...

Django-cms is absurdly good

Give this guy half an hour to explain why; he sold me. 

Swwwweeee-e-eee-eeet!

Sensor chip w/Active low pin 2 = *NUKE

Maxwell Technologies’ HSN-1000 radiation-hardened Hybrid Nuclear Event Detecto


Kyle : wtf do you use that chip for?
Kyle : bomb warning device?
Dr Tune: no it's to launch a retaliatory nuclear attack
Dr Tune: you hook the active low *NED output (via a fet) to the ignition system on yr ICBM
Dr Tune: optionally you could have a toggle switch or something
 Dr Tune: 4 safeness
Kyle : well at least it triggers on a detonation and not just spotting something in the air
Dr Tune: yeah I wonder how they do production testing
Dr Tune: chips prolly veh expensive
Dr Tune: anyway
Dr Tune: comedic, and I love it just has pin 2 as essentially *NUKE
Kyle : lol yeah
Dr Tune: maybe hook it up to a piezo buzzer or something, so if you don't notice that you've just been nuked, it'll let you know
Kyle : yeah i was thinking its probably part of some sensor network to notify the pentagon or something
Kyle : immediately adjust the defcon level
Kyle : or i guess its not defcon anymore
Dr Tune: ya someone in pentagon has haxored up an arduino
Kyle : go to purple alert or something
Dr Tune: well only what 5 defcons
Dr Tune: so can use an attiny

Snoop NFC RFID card with RTL-SDR dongle

It's been a big year for radio fun!
Playing with NFC / RFID tags recently it occurred to me that the RTL-SDR dongles could potentially be used to sniff 13.56Mhz tags.

As it happens the RTL tuner won't quite tune as low as 13Mhz, but.. the first harmonic at 26Mhz works great!

Here's a Mifare Classic 4K card being repeatedly read by an SCL3711 NFC reader. I wedged an antenna next to the reader, fired up SDR-Sharp and here we go...

SCL3711 reader + Mifare 4k + antenna to RTL dongle

Center signal = 13.56Mhz carrier from reader, side spurs = ASK modulated reply from card :-)

Next stop, demodulation and a nice cup of tea. 

Video:

Addendum - while video shows antenna strapped to the card, this setup seems to receive both card+reader signals just fine from 15 feet away!

Later:  Ok never mind the "15 foot" stuff - not true it seems. Because I was running RTL dongle + NFC on the same PC it was coupling the RF signals through the USB lines, making things look very much better than they really were. I tried tag reading with a non-USB-wired Nexus 7 and the antenna range (for the signal from the card) is as "near field" as you'd expect. So; handy and cheap but not ground-breaking :-)

Mongodb pros and cons - scalability, management in production

Here's a nice easy one...

Don't use mongodb, tune your SQL properly, fool!

I experimented with it a while ago and what I found almost exactly matched what this guy found.

Read what he says and believe.

http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb

I didn't go anywhere near production with Mongo, cos I found it basically didn't work very well and mysql (when given some attention) we find to be astonishingly reliable and speedy. (we do thousands of queries/sec/mysql box)

I don't normally hate on free sw, but kids are getting their fingers trapped in this one.

"Mysql server has gone away" or "Lost connection to mysql server" when using Amazon RDS for for backup or whatev's

Hey,

OMFG what a PITA.

You run long mysql jobs, especially on an amazon RDS instance, especially e.g. backup, and it randomly fails, esp as the db gets bigger, and esp after several hours.

Well FML!

The answer is all over Google; it's either

a) [most common] the "net_write_timeout" variable on the source server (e.g. that you're dumping from); the AWS default is like 60s, which is sensibly cautious if your clients are some crashy bullshit (as hanging result sets/cursors are obviously expensive to keep lying around). 60s is fine for a web app, but if your client is occasionally/randomly gets stalled for a really long time (think; EBS, Innodb reindex if you're streaming direct via a pipe from mysqldump | mysql to do server->server backups; which can be a fine idea depending on yr needs).

OR

b) [less common] the destination server that you're unpacking/writing to has timed out for similar reasons; you were in the middle of providing [usually a metric fuck-ton] of data in an INSERT or UPDATE and the server doing the insert got hung up on something randomly once in a blue moon (e.g. system backup) and boom; the mysql box you're writing too tells you to f-off.

Typical AWS timeout here (net_read_timeout) is like 30s.

Ok so there you go; AWS defaults are sensible for a high-volume web db trying to protect itself from bad clients. Backups occasionally classify as 'bad clients'. FML again.

------THE FIX:

--EITHER (easy,global)

a) Change your RDS instance settings (amazon control panel) to set 'net_read_timeout" (and write) to something bigger globally across all connections. You might pick e.g. 20mins. If you have a lot of crappy/dropping DB connections tbis might be an issue.

--OR-- (usually easy for client code, not for mysqldump)

b) If you're running client sql code (e.g. php,python) simply do "SET net_write_timeout=3600"or whatever (or read_timeout, depending if yr problem is in SELECT or INSERT/UPDATEs) on each conn after you open it and bingo.

The var is set per-connection. This works perfectly for client code but not for mysqldump backups which I'll get to below.

--OR-- (middling, fixes mysqldump)

If your problem is with mysqldump piped dumps vi

e.g.

mysqldump yadda | ... | mysql yadda

(I do this using 'tee' and pipe a copy via gzip into a backup file at the same time I copy a db direct from one host to another making a compressed copy @ same time with no limit on db size. ..actually that is why I'm writing this..)

The issue you see is when the target DB stalls (can happen for e.g 1-10 min at bad times) the source DB times out (quickly; 60s default) on the write socket. This is not AFAIK fixable with normal mysqldump without changing the server's global timeouts for everyone.

The obvious fix is for mysqldump to send "set net_write_timeout=blah" after opening the conn it uses for dumping. Wierdly I cannot make it do that regardless of options, so I hit up the src code.

Basically I patched mysqldump so it sends "net_write_timeout=somebigtime" to the source server AND prefixes "set net_read_timeout=blah" into the SQL dump it outputs.

This solves both ends of the problem, especially when piping from one server to another with msqldump | mysql - both source and dest servers set the timeout _temporarily on that connection_ to a nice long value, e.g. 1hr.

Fixing mysqldump so it sends "net_write_timeout"

So I basically grabbed the mysql src and compiled it (google), on an aws box.

(actually "yum install mysql-devel ncurses-devel" may be handy, prolly a few more)

You don't need all the mysql stuff, just mysqldump,

..but I compiled everything (./configure {google for opts} and make)

MySqldump is in client/ and all the guts is in mysqldump.c

The hack is utterly trivial;

at the end of "connect_to_db" before teh DBUG_RETURN I added

#ifdef MUNKY_HACK

my_snprintf(buff, sizeof(buff), "SET net_write_timeout=3600");

if (mysql_query_with_error_report(mysql, 0, buff))

DBUG_RETURN(1);

#endif

..which is most important and tells the src server to use longer timeouts just for the dumping.

IF you're being fancy and piping from one db to another, you may want the output dump to include a prefix telling the target db to use longer timeouts.

I addeed this to near the top of 'dump_table' as ;

fprintf(md_result_file, "/* Munky Hack*/\n set net_read_timeout=3600;\n");

It's that easy (it seems) to make this stuff work properly reliably