In addition, I was thinking about SSB64 and how with this I could change the button mappings to allow for C-stick smash attacks with the GCN controller. I haven't uploaded my changes to the code yet as I still want to tweak things.
You can see this in action in my short videos I've made on it
Anyone who has been watching my YouTube videos will know that I've been working on this USB isolator for quite some time (for no particular reason other than getting distracted by other projects). I figure now is a good time to post the project here on the forum so more people can check it out.
The boards pictured below are of rev2. I just finished off rev2.1 which fixes a few small things (such as LED placement) and adds a jumper header to bypass the linear regulator. This way a user can also use the barrel connector with a 5V supply.
I received inspiration for the project from other USB isolator projects on the internet. Mine features a few improvements to many of them:
- USB-B and micro-USB connectors on the host (upstream) side. - In addition to accepting power via the barrel connector (which goes through a basic 7805 low dropout linear regulator), there is also a micro-USB port for device-side power. This allows you to use the now common cell phone charger cube to power your isolated device. - Push-button switch for easy USB disconnection events. - Bypass jumper for linear regulator, allowing for 5V power from the barrel connector. - Encased in a small box to protect the IC from the world.
You can find it on my website: http://galvant.ca/shop/usb-isolator/ where I'm currently collecting pre-orders for anyone interested. Any and all support for my work is greatly appreciated and goes a long way to allow me to keep making OSHW.
Hey everybody, I've got another project of mine to show today.
Inspired by the USB Condom, the USB Wrapper helps protect your device against untrusted USB ports by severing the USB data lines and only allowing the power lines to connect through. This ensures that no data information can be transfered between the power source and your device. This helps against known attacks such as juice jacking: http://krebsonsecurity.com/2011/08/bewa ... e-jacking/
This however does present a problem. In legitimate USB chargers, the data lines are used to communicate to your device how much power they are capable of sourcing. The exact means by which they do vary between manufacturers. The standard calls for the D+ and D- lines to be shorted together, while companies like Apple will apply specific voltages on both lines depending on the charger. By entirely disconnecting these data lines, your device does not know any information about the charger, and will thus assume it is a standard USB2.0 port. This limits means the device will self-limit the charging rate to 2.5W, even if the charger can in fact handle more.
To deal with this, the USB Wrapper has two slider switches allowing you to tell your device what kind of charger it is connected to. This also allows you to mix and match chargers and device manufacturers which don't follow the same signalling rules. For example, an iPhone with a Samsung charger cube. It features selections for dedicated charger port (D+ & D- shorted), Apple, Sony, and open circuit. For Apple, there are 4 options, 500mA, 1A, 2.1A, and 2.5A.
Hey everyone, back with another project. The antiAFK is something I originally started working on almost a year ago, but its only been since 2014 started that I've been making real progress on all my projects.
Plus, I just finished my MSc the other day so now I've got all the time to work on my OSHW!
The antiAFK is essentially a stripped down Arduino Leonardo with the intention of sending occasional keyboard commands to the attached PC with the intention of preventing the user from being logged out of online games due to inactivity. This can help on high population servers where being kicked back to the login queue can mean that you miss a group event. It randomizes the time between presses (with a min and max), the key from a set of valid keys, and the duration of the key press event. The period, variance, and valid key set are configurable by the user through the CDC serial port.
I also have the board available on my website at http://galvant.ca/shop/antiafk/ . I feel bad asking, but I would appreciate any support if you are interested. I'd rather work full time on open source hardware than going out and getting a "proper" job. So any help, even if its just comments/suggestions are helpful.
Hello everyone! I've noticed that in the past I've gotten a few links to my GPIBUSB adapter project from this forum, so I figured I would make a dedicated thread for it.
A few years ago when I was in my final year of undergrad I was working at a fresh university lab (which I later spent my masters at). While setting up some equipment, I had to connect a bunch of T&M equipment to a PC via GPIB. However, I quickly discovered what a pain in the arse it is to get GPIB working. Specifically, I found that the Linux GPIB drivers do not contain MATLAB bindings. Well, if they did we couldn't get it to work. Getting it to work with Python was no problem with pyvisa, but this project had the requirement that we used MATLAB. Eventually we just installed Windows instead (which caused later issues with SSH but that's another topic).
A few months later I was thinking about that situation and set off to make my own solution. I decided to make a board that used a virtual serial port to avoid all these issues. This way any modern software could talk to a GPIB connected device.
This past weekend I finally finished up the third major revision of my GPIBUSB adapter board. Major hardware changes include swapping the pull-up resistors for the proper GPIB line drivers, as well as swapping the FT232RL for the newer FT230X. There is a number of software improvements from improved reliability to additional commands.
In order to help abstract the user away from having to deal with adapter-specific commands (eg: setting the target GPIB address, etc) my friend and I started a Python library project called InstrumentKit. Here, we took things another step further and abstracted hardware-channel specific instructions away. InstrumentKit allows you to communicate with equipment via Python while maintaining a consistent API across instruments and keeping you away from having to deal with the specifics associated with the physical connection. This means serial, tcpip, nix filelikes (eg /dev/usbtmc0), my adapter, etc are all opened with a single command (or a single line in a YAML config file). But that's all I'll say about that for now and I'll make another post at a later time with more details.
This project (along with everything else I do) is open source hardware. Sources can be found in a few repositories at my Github page. Do note that a few docs need some updates but the main files are there. You can also find the adapter on my website at Galvant Industries.
I have a few ideas for improvements in the next version, but let me know what you all think!
Oh, and I'll try to get a video of it in action in a few days.