Saturday, April 16, 2016

Wifibroadcast - measuring latency on a laptop

My method of measuring the absolute latency scene-to-screen involves the camera looking at the receiver screen which is partially obstructed by a smartphone running a stopwatch, all being recorded by a Casio EX-F1 at 600fps.

The darker one is the smartphone screen, the lighter, grainy one is the laptop. I picked shots where both numbers are not blurred as they are changing.
Phone has an LCD, not AMMOLED display, so it tends to blur fast changing stuff. Both displays (phone and laptop) should be TFT, so about as fast as a consumer-grade LCD can be.

The mathematical average of these 10 shots is 197ms. Not too bad...

Sunday, April 10, 2016

Wifibroadcast receiving on a PC

Yup, you definitely can watch on a PC. (And there's no limit on how many! :D)
Tested on a Lenovo x230 running Ubuntu 14.01 LTS x64 with a TP-Link TP-WN722N.

Installing wifibroadcast:
open Terminal or some other commanline and input:

  • sudo apt-get install mercurial libpcap-dev iw
  • hg clone
  • cd wifibroadcast
  • make
If there's no screaming or error, you may proceed with connecting the wifi card and waiting until it lights up. Then proceed with setting it up:
  • cd $HOME/wifibroadcast
  • sudo ifconfig wlan1 down
  • sudo iw dev wlan1 set monitor otherbss fcsfail
  • sudo ifconfig wlan1 up
  • sudo iwconfig wlan1 channel 13
Run the program with:
  • sudo ./rx -b 8 -r 4 -f 1024 wlan1 | gst-launch-1.0 -v fdsrc ! h264parse ! avdec_h264 !  xvimagesink sync=false
Once there is a valid signal from the transmitter, the wifi LED will start flashing and shortly after you should see a window with the stream pop up. 
To infinity and beyond!

You can close it with ALT+F4 and stop the wifi with 

  • sudo ifconfig wlan1 down

To start it up again, repeat the setup (no need to install anything again) and run the program. Here I'm using wlan1, because I'm assuming that like me, you'll be using a laptop, so wlan0 will likely be taken by the internal wifi card. This may however not be the case, unless you are sure, check with ifconfig
Hopefully I'll be able to cobble up a script soon...

Saturday, April 9, 2016

Dual boot for Windows 8 with Bitlocker and Ubuntu 14.01 LTS, UEFI version

  • Make sure you are booting in UEFI, not legacy mode. Seriously, check that shit.
  • Turn off secure boot.
  • Windows 8 goes first. For good measure, make sure the drive is GPT, not MBR. This can be done even in the install by clicking the "repair" and clicking your way to a commandline (tons of how-to's on teh interwebs)
  • If you need to make a UEFI-capable install USB flash, simply use diskpart to: 1) clean the drive 2) convert to GPT 3) create a primary partition DO NOT mark it active!!! 4) format it to FAT32 5) assign a letter. Close Diskpart, if you have a ISO somehow extract it (W8 and later can mount ISOs as a virtual drive; winzip can open it like an archive), dump the contents straight to the flash.
  • Create a patition for windows, make sure you leave enough space for Ubuntu, 10GB seems to be the recomended minimum. Windows installer should tell you that it's going to create additional pratitions, there should be a total of 4 including the one you made.
  • After the install and initial config, set up Bitlocker, save the keyfile outside the encryped drive, encrypt drive. Take ownership of the TPM. Reboot and make sure it works.
  • Disable fast boot, otherwise stuff WILL BREAK. There's little difference having it on for SSDs, magnetic drives are a different story though. The checkbox can be found in power management ->buttons setup ->the top "change what you can't now..." checkbox -> allow fast boot (uncheck).
  • Install Ubuntu. Bootable USB the same way as for windows. I chose 14.01 LTS, but I see no reason the newer versions would not work. Run the setup in "install alongside windows" mode. Partitions can be shrunk later. Make sure you note down all the passwords and pass phrases you set up. Test Ubuntu boot.
  • Test Windows boot. Most likely it will require you to input the key that you should have saved outside the encrypted drive. If you didn't, you're a dumbass and now have locked yourself out. Best start over.
  • boot Ubuntu, Change UEFI boot order via efibootmgr - in terminal type sudo efibootmgr -v  to see whats going on (you'll see quite a few  things with 4-digit numbers, and the boot order), then type sudo efibootmgr -o with the altered boot order. You'll most likely be switching the 2nd for the first. This is not fuck-up-resistant! You screw up - no worky worky!
  • If windows boot works, reboot again. If it keeps requesting you input the key every time you boot, you have to take ownership of the TPM again. If the greedy bastard keeps insisting you input the key over and over again despite you taking ownership of the TPM, something's fucked up and you have a long Google session ahead of you.
  • You will most likely not see any mention of Ubuntu during boot anymore, but fret not, try mashing whatever key brings up the boot menu before it starts booting, you should see "windows...something" and "ubuntu". This will be the way for choosing. Should also work for additional UEFI installs, the names seem to match the directories in the \EFI  
  • Turn secure boot back on
  • Install drivers and crucial software for both systems, make a disk image. Seriously, do that, the time you save when reinstalling is makes this worth it. Save the keys, passwords and passphrases with the image, as it's useless without them.
  • Enjoy your dual-boot.

This was done on a Lenovo x230 running an aftermarket SSD, Windows 8.1 and Ubuntu 14.01 LTS, all from UEFI-capable bootable USB flash drives. Both OSs run in secure mode with no bitching.
The boot menu is slow to load (10s for me), but that seems to be feature, not a bug.
Your results may vary, as i uderstand UEFI implementation is not perfectly the same for all PCs.

Thursday, April 7, 2016

Dual boot for Windows 8.1 and Ubuntu with encryption galore, MBR version

word of warning - this is for patient people only. If you are known to chimp out after 4 hours of something refusing to work as it's supposed to - I'd suggest something different...

On to the magic, why would you do this?
I have a Lenovo x230 laptop to which I cheaply bought windows 8.1. Once you get Classic Shell installed, it even mostly feels like W7 which boots insanely fast. I'll gladly admit that I'm a windows guy, it's what I feel at least slightly comfortable working with since I practically grew up with it. Venturing into Linux territory usually means Google is working overtime and it takes a fuckton of time to get anything done, because everything is different. Don't even get me started on OS X.
That being said, Linux allows for certain unicorns that are not possible (or horribly difficult) on Windows because of the way the drivers work. Monitor mode for WiFi adapters is one of those things, extremely useful if you wish to do any type of poking with WiFi, good or bad. It's what allows Wifibroadcast to shove packets into the WiFi adapter without caring where or if even at all the end up at. It also allows receiving mangled packets (only some chipsets though, Atheros has long history of that).

Why would you do it like I did?
These days, a healthy dose of computer paranoia tends to be quite reasonable, given how much sensitive info can be extracted out of your daily use PC. Just the windows password is the equivalent of a 1 meter high decorative fence around your house. Enough to make normies understand that you don't want them rummaging through your stuff, but obviously very easy to defeat by multiple methods. So, if you want something a little more resilient, there's encryption.
Now common 256bit AES is enough to make even American 3-letter agencies pissed (btw it's approved for use on top-secret information), your average tech-sawwy criminal has no hope in hell of defeating the encryption itself, (it's much easier to literally beat the password out of the owner) at least not in his lifetime.
Naturally, the one thing I was satisfied with on previous OS versions doesn't really work for W8, so I have to use Bitlocker. Because of how this thing works, IT needs to be the first thing to boot, otherwise it's a no-go. Yes, having to boot most of windows only to tell it that you want linux and letting it reboot is kinda silly now that I think about it, but until M$ acknowledges that they could do a better job on the bootloader, it's the only way of running it like this.
If it weren't for the Bitlocker part, you can happily use the automated install and let linux configure everything for you. But if you need your tinfoil hat, it's hacking time!

Loosely following this guide, (loosely meaning not everything was exactly acording to this guide, there were others as well...), I created 2 partitions for Linux, one for root, the other for swap. The root one needs some space to be usable, exact figure depends on what you want install, but mine is roughly 20GB. Swap should be more then happy with 4GB, although I used 8GB. Don't know why (the machine has 8GB RAM), but I saw this once the win was set up and I didn't feel like doing it again (can't move the boot partition without breaking booting).
Then I let windows create it's boot partition and gave it some reasonable space for C:, roughly 50GB and let it install. Once that's done and you have most of the stuff installed, turn Bitlocker on, configure the TMP, then turn it off again. (where have I heard that before...oh right, I have the misfortune to do IT support for a living...).
Once that's done, I'd suggest making an image of the machine, because if you fuck up the following steps, it's really hard to fix. Much easier to just restore. I personally like Clonezilla. I tend carry in on a multiboot flash along with other goodies.
Install your Linux of choice, but you can't use the "auto" install, you have to do it manually. Tell it to use the bigger linux partition as /root and format it to EXT4 and to use the swap as...swap. Install everyhing. Once that's done, DO NOT let it place the bootloader into the MBR (if you do, windows will not boot), instead plop it into the /root partition.
If you've customised the crap out of the thing during install and windows STILL boots, make another image, saves time if you fuck up the bootloader.

Now comes the "fun" part. (link to source)
Boot some kind of linux from a flashdrive, somehow determine what is your partition of interest (gparted has a nice GUI; or just fdisk -l) and make note of it, it has to be the /root (or whatever you stashed the bootlader into). Do dd if=/dev/sda1 of=/tmp/linux.bin bs=512 count=1 , replacing sda1 with the patition with the bootloader.
This will make and copy linux.bin into the tmp folder (it's in /root). From there, copy it either to a flash drive or if you feel like it, plonk it straight into the root of C:. Boot into windows.
Launch cmd with admin rights and do bcdedit , it should dump the current state.
Now, do bcdedit /create /d “GRUB” /application BOOTSECTOR , you can replace the "GRUB" with whatever you want to name the entry (it will show up as the selection of what to boot). You will get a long GUID in curly brackets, copy that shit.
Now, do bcdedit /set {GUID} device boot , {GUID} is what you should have copied from the previous step.
Next do bcdedit /set {GUID} PATH \linux.bin
then bcdedit /displayorder {GUID} /addlast to put it below the win8 selection,
then bcdedit /timeout 10 , the number is timeout in seconds. I recommend less, 5s is plenty enough.
The final step is bcdedit /set {LinuxID} device partition=C: , this tells it which actual partition it can find the linux.bin.
Once you feel you did all that you should, do bcdedit again and check that the second entry looks something like this:
Real-mode Boot Sector
identifier              {a33bafb4-fc1d-11e5-8259-3c970e62ae2e}
device                  partition=C:
path                    \linux.bin
description             Ubuntu
Obviously, the identifier will be diefferent and the description will be whatever you made it.
The device part is what took me almost 8 hours of trying various things, including different distros and what have you, only to realize that there is no way the system can know where to look for the bootloader. After extensively searching how to use the bcdedit /set , I found this, did it, tested it, found it working exactly as it should, did the "yatta!" and went on to post a comment to the M$ blog article, only to find THAT EXACT THING THAT TOOK SO LONG TO FIND was there all the time... read the comments...
If both systems boot, turn on bitlocker, make sure TPM is running (otherwise you'll have to manually input the long key every time) and let it encrypt.

Last but not least, make a partition on the remaing unused diskspace and format it to NTFS. Then install Truecrypt (or other encryption SW of your choice) on both systems and encrypt the partition, it will serve as a safe datastore that both systems can access.

Now make the final image of the machine and store it safe, unless you want to ever go through this again. Enjoy your reasonably secure dual boot system.

Saturday, April 2, 2016

polishing the turd some more

To address the light performance and increase the view angle, you need a different lens.
To hold the lens, you need a lens holder. Like this one. (not optimal*, but can be made to work)
Before you buy said lens holder, note that the hole spacing on the camera module is 21mm, not 20. Holders with 21mm spacing seem magically more expensive, even though they are made from the same material using the same technology. Before you put on the new lens, the old one obviously has to go. This needs needle-nose pliers and a bit of persuasion, but it's not terrible hard.
Because of the hole spacing, I had to secure the holder with wire and then glue it to the PCB. Then I could screw in the lens and focus it.

So, without further ado, I present:

Totally not a bomb mk. II

Not a bomb even in the slightest

On the back is a different switchmode converter, not sure about the topology, but it goes both up and down. Uses 2 inductors and doesn't invert the output voltage. buy here
Efficiency is not all that awesome, still draws 2,68W, so pretty much n=80%. Also, it makes audible noise, (discontinuous mode), so it's not matched well for the current draw...

voltage is inverted, so it's rising in the graph
New toy btw. Would be perfect if they added some math functions to the app.

trash TV in action
Viewing it on the trash TV, the latency is barely perceptible, probably close to what the project author measured.

Latency seems to be betweeen 140-170ms, so unless you need to go crazy fast, quite usable.

Friday, January 1, 2016

Polishing the turd

After some looking at the datasheets and doing some number crunching, I came to the conclusion that the inductance of the buck regulator is too small, not too large...
Measuring the size and winding of the original one, inductance calculators gave an estimate of about 300μH, which is reasonably close to 330μH that it probably was.According to the datasheet, for 12V input, 5V output at 0.45A, I should be using a 470μH inductor. So I dug through my junk pile, found a T106 size iron powder core that was green with one side blue, meaning it has a permiability of 75 and is good to about 1MHz.
"Ring core calculator" (freeware program) said I need 70 turns (243cm of wire), couldn't find what wire I should use, so I just grabbed the first reel I came across, 0.255mm diameter which should be sufficient. Half an hour of winding later, I had in inductor that replaced the original one, only downside is that it weighs 36g instead of the 27g of the original one...the core is ridiculously large for such low current, but I don't have anything smaller that can fit enough turns for 470μH.

It's quite interesting that with switchmode regulators, drawing less current means you need more inductance to function properly, and vice versa for larger currents, where the core size is predominately dictated by wire thickness, as you need just a couple of turns. (but you have to be able to physically stuff it in/on the core)

For 5V out... © ON Semiconductor
The number is inductance in μH, the letter has to do with current rating.

TL:DR - input power is now 2,81W (instead of 3W), making n=76,6%, so - yeah, improvement, but nothing to receive a prize for...

Thursday, December 31, 2015

FPV for the 21st century

Saw a couple (of dozens...) of youtube videos with people mounting FPV to various RC things. The videos from cameras themselves looked fantastic, but to transmit the video feed to the pilot, an analog link is traditionally used. While the transmitters and receivers are small, relatively cheap and yet use fancy modern stuff like digitally controlled PLL tuning, it's still analog video, even at perfect conditions you have 576 visible lines at most, a far cry from 720p or 1080p we are used to in digital video that has been around for almost a decade now.
There are a few working attempts at transmitting amateur video over DVB-T, but the problem is that the cheapest variant (to this day) requires a modulator that costs $170-$230, not very cheap. Does not include the cost of any other vital part (camera, RasPi...)
Others that I saw use software radio, this particular one a BladeRF ($420), and I would guess that it should be possible to use HackRF (~$300, depending where you buy it from) or the HackRF Blue ($215, or $150 for a "factory second" version), which is a cost-optimised version of the HackRF. One more that I remeber used an URSP 1 (>$700, the newer versions cost even more).
All of the software radio versions however require a fair bit of floating-point maths to be done, way more then a measly Raspberry Pi could do, so they are not practical as FPV transmitters.

So, not being happy with the analog quality and the pricy-ness of the digital solutions, I've been putting FPV off for over 2 years now.
Recently I noticed Wifibroadcast, which simply put uses "monitor mode" to force certain wifi chipsets (only some can do this!) to completely change the way the protocol works, which allows not only to receive mangled packets (under normal operation wifi discards packets whose CRC does not match), but to also transmit modified packets. One other important feature of Wifibroadcast is that it's one way, meaning that the transmitter does not need to receive any conformation from the receiver (again, under normal wifi operation, the transmitter keeps re-transmitting a packet until it gets an ACK from the receiver or times out and quits trying). The combination of one-way transmitting and ability to receive mangled packets means that with degrading conditions (like the transmitter getting too far) the link fails "gracefully", not instantly like normal wifi would.

So, (my) shopping list:

1x Raspberry Pi Model A+ with Coupé Royale Pibow (£20.83 GBP (~$29.5) from )
1x Raspberry Pi Zero + Adaptors (£6.67 GBP (~$9.4) from
1x OV5647 Sensor camera ($15 from Ebay) *
2x TP-Link TL-WN722N ($14.5 each from Ebay)
2x microSD cards, 4GB at minimum ($3 each? from Ebay)

total: $88.9 USD

I've had the wifi adapters and SD cards for less, since I work at a computer store (employee discount :D).
*The camera has fairly crap optics, which is not very surprising since it cost less then 1/2 of what the ones with better optics do. It also is not wide-angle enough, so it's unsuitable for me (kept snagging the car on obstacles, because I couldn't see them), will probably be changing that. But it works for a proof-of-concept. There are several options for the camera, for example with and without the IR filter, the rest is all about the lens.
Since not everything arrived before Christmas (like it was supposed to...I'm looking at you Czech Post), I didn't have all the essential parts until now.
So, after a couple of zip-ties, about 50cm of kapton tape and one hour of hacking, most of which was spent troubleshooting the 5V switchmode regulator (amazing how much flustration can a forgotten resistor do...), I had this:

No officer, this totally is not a bomb, honest!
The green LED flashes when transmitting...seriously though, some might see this as a bomb :D
Pictures were shot with a crappy cell phone camera with clearly not enough light. Sorry about that.

The box from laser-cut acrylic contains the Pi A+, below it is a 3S2P lithium pack scavenged from a laptop battery (was 4S, but one pair was dead). The mess of wires on the right with the inductor and grossly oversized heatsink is an LM2575T-ADJ buck regulator providing 5V for the RasPi. Junk from a disasembled old project. I could have made it output 3.3V and feed the Pi directly (it has an internal 5V to 3.3V regulator), but I do not trust the thing enough to do that. If it goes apeshit and starts feeding more then it's supposed to, the Pi will let out the magic smoke. The 5V input on the other hand is quite idiot tolerant, as it survived 9V. (forgot to remove an original resistor from the board as I installed a new voltage divider into the feedback loop, it happened to be in the "lower" part of the divider causing it give out much more voltage).
The bare board (with the antenna) dangerously sticking out is the TL-WN722N. As mentioned in the picture caption, the thing does flash when it starts to transmit, which draws unnecessary attention and eats power (albeit not very much). The board on the copper wire with the flat-flex leading to it is the camera module. The black part is 8.5x8.5mm, really small. Might also try to change the flat-flex to normal wires to make it more flexible.

Getting it to work is stupidly simple, download both the precompiled TX and RX images from the Wifibroadcast GitHub, load the images onto the SD cards (Adafruit has a nice tutorial), plug the cards into respective Pi's, connect the camera, wifi dongles, power, monitor and off you go. If you did it right, it will be plug-and-play, don't be scared by the commandline dump on the receiver screen, you just have to wait until everything loads and starts.

The tiny thing on the drum with the cables is the Zero. Receiving wifi is on the stool down left.
Picture quality (and latency!) will depend on both the camera and monitor. Currently I'm using an LG smart TV, but that will change once the damn display finally gets here...
The picture does not do justice to the quality, even with the shitty optics the $15 camera module has, it's quite reasonable. Low light performance however is atrocious (not surprising given the size of the lens), best to this outside in daylight.
Latency is well perceptable, estimated guess is somewhere on the 500ms mark. A lot like a good IP security camera with direct cable connection. The main suspect is here the TV itself, not Wifibroadcast.
Sadly I can't record the HDMI output directly, the TV will not allow it (cause hurr durr pirates...fuck you DMCA, fuck you with a cactus) and I have nothing else that can record HDMI. Will have to see if the receiver has enough gnomes free to record the output somewhere...

When booting, the current was jumping around 100mA, once the camera kicks in (h264 encoding) and wifi starts transmitting, it jumped to 260mA (couldn't use low range, so I just round up the last decimal).
during boot, jumps between 60-150mA

Current times voltage equals power, in this case 3 watts. Considering that's with the sub-optimal regulator design (fairly low frequency and grossly oversized inductor), not too bad. I will be doing more measurements with a better regulator providing 3.3V directly.
Sadly, the Zero does not have the camera port or the connections to it on the board, which is a shame, so you have to use an A+ for the transmitter. Using the more powerful Pi versions for the transmitter is counterproductive, as the greater heard of horses also eats more (and generates more waste heat).

Obvious thing to do at 6 o'clock in the evening...

Yes, that's a zip-tie

I was kinda in a hurry to get it moving...

All it's missing is the kitchen sink...
Did just a few quick indoor tests, big surprise, a 1:10 RC car is too big for driving around a flat without wrecking it. Since it's dark, freezing and now snowing outside (and the 100cm TV is kinda hard to carry around), so I have to wait for better weather and a small display.

To come:
this (Zero has the same header, so it should work)
- some miniaturization (remove USB connectors and hardwire the wifi, use a more modern buck converter)
- weatherproofing
- lowering the power-hungriness
- dealing with the slight EMI issues (RC car and the wifi interfere with each other in various ways)
- different camera module (huge lens, maybe no IR filter for better low-light performance)


So I measured the 5V side, and the consumption is when transmitting is 2,15W, which is pretty much dead on 70% of the regulator input, so, quite a shitty buck regulator. A properly designed one should be capable of at least 85%, over 90% if done really well.
However keep in mind that these measurements do not include the absolute deviation, I'm too lazy to look it up and count it, if you're bored, I used a UT61 multimeter, current was on the 10A range.
Also there's the problem of switchmode PSUs, which notoriously confuse the fuck out of multimeters by the high frequency ripple, the UT61 is a true-RMS meter, but a cheap one, so...