I know a lot of people dislike the original Amiga mouse and use modern mice on their computers but I feel it’s mostly because of the ball. What would be perfect is an Amiga mouse but with optical sensor.
So I made it. For my PC.
Read the rest of this entry »
There are many “Mini” computers and consoles that have already been 3D modelled. However I didn’t find a Vectrex anywhere. I had already been doing work on a Vectrex Emulator and decided to model my own and make it work.
The heart of the system is the VoCore I have been playing with on and off for a while now. It’s not super powerful and pushing the pixels over SPI is quite slow, but for something like the Vectrex emulator it does it ok. The screen is a cheap 2.2″ SPI LCD off ebay, originally a phone screen but now very commonly used by the Arduino crowd. It has a touch screen but that is not connected in this case. This is my first VoCore board and I didn’t wire up as many GPIO or even the hardware SPI so the few (4) working GPIO I have broken out all go to the LCD to draw the image.
I used Google SKetchup to make the Vectrex case. I exported it and loaded the mesh into Meshlab to clean up and scale.
Finally it was printed on my M3D (Micro 3D) printer in PLA. I took many prints to get a good one, with lifting/curling problems and many other failures as well as adjustments in size. When I finally had the thing done I realised 2 things.
1) I hadn’t included mounting posts for the LCD.
2) I hadn’t included any way to join the front and back of the case.
Oh well, what else is Hotmelt glue for eh?
The Emulator itself is a port of VECX that I modified to write directly to my LCD instead of using SDL or other graphics method. Power comes from a small LiPo inside and a 3.3v LDO to feed the VoCore and LCD. This makes it totally self contained and portable, along with WiFi it makes it a nice little unit.
The STL files for the case can be found here.
Final outcome? Watch a little demo here,
And a better quality video here,
So. I added a heatsink to the chip to control the raging fires, it helps but not a lot.
I also worked out the touch controller and hooked it up to the GPIO pins leaving the LCD on the hardware SPI (all working now). This let me write a little sketch app,
The extra touch space at the top works as four soft buttons. It’s not very advanced, just proof of concept for the touch controller.
Lastly. More emulation. I ported VECX to the VoCore. Now it works better with software GPIO due to the time spent on each system call for the hardware SPI and the fact it does lots of lines. Each line calls single pixel drawing which is at least 9 bytes per pixel, all called individually so I can toggle the command/data register
With software SPI it runs pretty much full speed! This is only a problem if I want to swap between my other stuff and the vectrex app as I have to re-wire the screen
Why are Skylanders so hard to hack? Well. Without revealing anything that isn’t already actually public, here are some details on what’s going on.
Skylanders are MiFare classic compatible.
(What I am about to say here is public knowledge and in no way secret or hacking related).
Mifare Classic has 16 sectors (each with 4 blocks of 16 bytes) on the chip. Each Sector has an access key (2 actually but nobody ever uses the second).
You can NOT read a block without it’s key (each Sector of 4 blocks has one key so 16 keys per chip). It is impossible to get a single byte of data off a Skylander without the key for the block you are trying to read.
The only data you can get is the UID of the figure (it’s RFID Address/SN) and a couple other bytes used to pick which card you are trying to read. All this is part of the NXP MiFare standard and can be researched with not a mention of Skylanders. It’s a well understood technology.
The portal has some math deep inside it that it uses to calculate the figures keys, once it has done this it can read any data block on the figure. This means the keys are NOT sent to the portal via USB or even stored in the firmware on the portal. You can’t extract them that way.
Data stored on the chip (figure) is sent back to the console from the portal after reading but it is STILL encrypted. Activision chose to encrypt the data on the figure AS WELL knowing that the portal could be used to retrieve that data by almost anybody.
This is NOT part of the MiFare standard, it’s an added layer of encryption put on the data that is stored itself.
The first block is not encrypted by Activision, this contains the figure ID and a few other bits that never change. All editable data is encrypted. This is the bit that the “first” hacker worked out making everything else possible. However, even reading the data doesn’t let you change it as there are checksums that prevent writing without knowing the formula to put the correct checksum byte back on the figure. Without that the new data is “corrupt” when viewed in game.
So, with only a Portal and basic skills with USB you can read all the data from a figure but it’s useless except the basic info on what figure it is (which is write protected).
I have yet to see the Amiibo or Disney Infinity figures to know if they are the same but would imagine if they use MiFare Classic that it’s not going to be a huge leap to assume something similar.
So I got the VoCore alpha a while back. It didn’t work. Turns out a design flaw meant a modification was required to get it running. I got two, and they were both b0rked.
The 0402 components required for the fix are what I class as “dust” and the two modules were quickly shelved for “future use”. Or not….
Roll forward some months and I manage to gain access to a stereo microscope and some tiny tools. I fix both VoCore and solder up some breakout boards for them.
What to do? Well, lots.
Firstly USB was configured with sound and HID as well as storage. I got a webcam and did streaming video, a USB sound card and played internet radio and fiddled with all the normal stuff openWRT gets to do.
Then I hooked up a small Nokia display (Thanks Sparkfun!) using SPI (software only, hardware SPI pins are not broken out on the VoCore alpha board). A quick port of an old NES Emulator later and I have this,
NES Emulator on YouTube (This is sped up as the emulator was slow when the video was filmed. I have since increased the speed to be almost playable)
After this success I moved onto the old favourite, Doom.
Doom on VoCore (This video is realtime, but not playable as the fps is far too slow).
So current state is that the VoCore is a great little board that is quite capable. I have started to get hardware SPI working by hooking onto the flash SPI pins but am still having speed issues. The goal is to bring up the speed and then work on a framebuffer driver for the VoCore.
Any week now all the original Kickstarter backers will start to receive their VoCore boards and I think then the fun really starts
I had been trying to withdraw my money for months but they were just delaying and making excuses on approving my account to prevent just that. In the end I lost everything.
Anybody that feels sorry for me can donate here,
Not much you can do except move on and curse the people that said to use MtGox because it was “safe”.
So I built myself a clever clock.
One I never need to set, even during Daylight savings.
One that monitors the temperature and lets me remotely log it.
This is the clock to end all clocks. I will never need another one ðŸ˜‰
(Till I build a better one)
Full details here.
Ok, so I finally caved in and bought some Skylanders stuff cheap on ebay. I got a second hand Portal and game for the 3DS (for my son, honest). Now, it didn’t come with figures but the save games had 2 figures cached so we can still play.
Looking for figures I found the start set figures were pretty much nowhere to be found, so to get them I bought a PC starter pack, with Portal and Game.
Now I don’t want to play it on the PC and will probably resell the PC game, but out of interest (before the PC one arrived) I bought just the Wii game with no portal and no figures, just a disk.
The 3DS portal with USB cable WORKS with the Wii version! I have yet to try the PC portal on the Wii but as that has USB it should work too, plus it holds more figures.
So, it looks like for compatibility the 3DS portal is best, working with the PC, the Wii and the 3DS (maybe xbox/ps3 too?). However it only holds one figure because it’s smaller.
Turns out the system used is a standard ISO RFID so lots of RFID cards trigger the portal, obviously they don’t read as figures but its funny to see your oyster card trigger the Portal of power as if you put a figure there.
So, My figures arrive and I play. For no reason one of them corrupts.
I have NO idea how to fix this in the Wii version I am playing, but luckily I have the 3DS version and DO know how to fix it in that.
I place the figure in the portal and the 3DS offers to reset it, I do so and it “works”.
Sure enough, the Wii recognises it too.
Worried by this I decide to backup all the figures right away, The first two backup no problem but the figure I “fixed” will not backup and gives errors.
Is it possible the Figure is damaged? The Wii/3DS still read it but the PC won’t back it up. Very strange.
I built a quad-copter (That’s for another post!) and bought a cheap chinese 6 channel TX.
It sucks (The TX that is).
I built my own TX from scratch using a 2.4ghz plugin RF module designed for converting 35mghz transmitters into 2.4ghz versions.
The base of the TX is a PS2 pad, the vibration motors were removed and the control chip desoldered. An AVR was installed in one of the “arms” of the pad where the motor was removed from.
The two sticks were connected directly to ADC0-ADC3 on the AVR.
It turns out the pad had “analogue” buttons and these were not good enough to trigger the digital inputs on the AVR. The solution was to fit 4 small micro-buttons behind the shoulder triggers to provide a good action. The top buttons were ignored.
These 4 buttons trigger the “aux” channels, sending a value around 1500 when off and 2000 when pressed. This allows me to trigger options on my quad.
To power the whole thing a small 500mah 3.7 lipo was fitted inside the radio TX module and a 3v to 5v step up adaptor fitted inside the pad. A lipo charger with mini-USB connector was fitted near the old cable outlet.
The LiPo charger outputs 100ma, so 5 hours to fully charge the battery, while the step up converter is capable of 500ma max, so 1 hours maximum run time.
I have yet to do a test to see how long it works in actual usage, but I expect more like 2 hours+ in normal use.
The code to generate the ppm signal is from an open source project called Funkenschlag by a friend from IRC.
So, after google killed the Google PowerMeter api I got the incentive to finish my own project using it. Odd huh.
I wrote loads of code to hook into the google API ages ago, but never got the hardware setup. Now After Google announce the death of the API I finally cracked the last part of my hardware issues and have live power monitoring of my electricity meter.
The key difference to most here is that its NOT a clamp type sensor. It counts rotations of the meter disc itself. It is therefor accurate and matches exactly what I will be charged for.
There are three parts,
1> Pic (UBW board) with IR reflectance sensor
2> Moxa Serial to Ethernet convertor
3> Database server
The Pic board counts rotations of the disc in 1 minute increments. Every ten minutes it connects to the server over serial (to ethernet UDP) and uploads all ten readings
The server saves these into a mysql database.
I wrote some PHP code to generate graphs of various data, this is proving to be the hardest part. Getting the data to look good.
Please excuse the awfull graph but I shrank it to make it fit nicely in the blog post, in the full version you get it nicely labelled and some extra info like average KW/h and total KW/h for the time period selected.
The biggest problem is the jaggedy graph, this is a side effect of the fact I count rotations per minute. Rather than time each rotation. Because the average rpm is low I only get about 1 rotation each 30 seconds. So its very easy to get a reading of 1 followed by 2 by 1 by 2 etc as that second rotation moves slightly back and forth over the 60 second boundry.
I am looking at ways to smooth this out without distorting the data too much.
I used the PIC UBW board because the USB port allowed me to compile code and program the pic in <30 seconds without unplugging anything. The serial to ethernet converter remained connected to the serial port so my development cycle was quite fast for the PIC code. I did some simple software debounce of the IR sensor (just in case) but it doesn't seem to be needed. The end result is completely non-invasive to the meter (yes, in the pic you can also see my OWL clip on sensor, this is not part of the new system and only runs a small LCD by my PC). The next step is to find a sensor that will trigger from the gas meter and allow me to monitor that too. They are close together so the hope is I can use another input on the same PIC and upload both sets of readings at the same time. This graph has allowed me to identify individual appliances by time and watch their power use, with a little more detailed study I will eventualy work out the power profile for each device and possibly predict when each one is turned on and off purely from the graph data! I can spot my fridge, my oven and washing machine already.