Skip to main content

Show Posts

This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.

Messages - scasagrande

Project logs / Gamecube controller to N64 adapter
Hey everyone, its been a while since I posted here about my projects.

Today I bring to you my Gamecube controller to N64 adapter. Basically I was playing my N64 and was sad about how the analogue sticks are getting old and loose. So I did some research, found some Arduino code someone had already written (http://, and designed a small PCB around this. You can find the KiCAD files on GitHub http://

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

First video:

Update with C-stick smashes:
Project logs / Re: GPIBUSB Adapter rev3
Hey everyone, got another update for this project to share.

After working closely with a few individuals it was discovered that some of the pre-existing GPIB software (such as KE5FX's tools) has some hardcoded serial port settings, one of which being the use of hardware flow control. After getting builds of the software tools with these disabled, some buffer problems were found using the default settings, under Windows, without the flow control. Running the software with WINE on Linux did not produce these issues. With some small tweaks to either the software or to Windows USB settings would fix the issue but that's not very intuitive. A better long term solution would be to wire up the hardware flow control lines in the next hardware revision for use in a future firmware update.

That's what I've done with the revision 4 PCB. In addition, I grounded a few unused digital lines on the micro to be able to, starting with rev4+, check what the hardware revision is in software. I also added two LEDs to the FT230X to allow it to signal on TX and RX.

Project logs / Re: GPIBUSB Adapter rev3
Thanks! You can always pick them up on my website if you want to financially support my work and future firmware development. I understand that's not an option for everyone so if you choose to build it yourself, be sure to send me a picture!
Project logs / USB Isolator
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: 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.

As usual for all my work, everything is OSHW and the sources can be on my github page:

Project logs / Re: USB Wrapper
In the future I'd appreciate the business, even if you're looking for un-assembled boards. I'm trying to work on OSHW full time instead of getting a "real job". I'm almost going even on a monthly basis, and I don't even own a car.

But hey, its within your right to order them else where.
Project logs / Re: USB Wrapper
Resistors are all 0603. As an exercise to the reader, you'll have to find the switches yourself!
Project logs / Re: GPIBUSB Adapter rev3
I just uploaded a new build to the dev branch on GitHub which speeds up command recognition. Before this build I had the micro do comparisons on input vs each stored "valid" string in memory until a match was found. This resulted in a lot of unneeded character checks.

With the update, only the characters that differentiates each command are checked. So, while this technically reduces how strict the language set is, it speeds this section of the code execute up enough that large numbers of internal commands being sent no longer require the occasional delay to prevent the buffer from being filled.

Next I want to investigate speeding up the port manipulation and see if that improves performance at all. If it does make a difference, both of these changes will be packaged together in a final firmware v6.
Project logs / Re: GPIBUSB Adapter rev3
[quote author="mountaindude"]So I am pretty much a GPIB noob... sorry if I ask something totally obvious.

Would I be able to control my GPIB / HPIB equipped tools with this board?
Such as a HP 3478 bench meter, Fluke 8842 bench meter, HP 6632A power supply (to name the ones most commonly used around here).

Would it work from a Mac? Guess it should, as long as a terminal program capable of fast serial is used, right?[/quote]

Hey sorry I missed your post. Yes as long as those instruments have GPIB/HPIB ports on the back (and they are functioning!) this project will let you control them.

I have never *personally* used it with OSX, but I know that FTDI does have an OSX driver so it should work just fine. If you are going to use a terminal program be sure that it sends your entire string at once, rather than sending each character as you type them out.
Project logs / Re: GPIBUSB Adapter rev3
After many days, I just finished off firmware version 5 for my adapter. This is probably my biggest update yet. A lot of people asked for compatibility with the Prologix commands so that's what I focused on. Here is an overview of the new firmware:

- Nearly all Prologix command set support. The adapter should now work with some pre-existing software tools and examples on the internet that were originally intended. Some will require a few changes for baud rate and flow control settings.
- Improved termination character handling
- SRQ support (but no parallel polling, only serial)
- Improved stability
- Device mode (first version so there may be fixes in the future)
- Most settings can be stored in EEPROM
- Basic FIFO buffer for data sent from the PC

The next update will probably focus on optimization. As usual, everything is open source and can be found at
Project logs / Re: USB Wrapper
Yep! I just finished my MSc and I'm trying to do OSHW full time.

Is your plan to just vary the voltages on D+ and D- until you find the maximum charge rate? Totally an option but I've found that many devices will require you to disconnect the 5V supply between changing the voltages on D+ and D-. IE the device will set its charge rate when connection is initially made and does not continue to monitor those other lines. You'll need to break the 5V connection each time while hunting for that optimal rate.
Project logs / Re: USB Wrapper
A current monitor would probably increase the BOM by too much. I'd like to keep this one as minimal as possible. I am thinking about a more "advanced" version which could include a current monitor. Let's see if people like this version first!

Lots of devices use the shorted configuration. In fact, everything that actually follows the USB charging spec does. My Samsung Galaxy Nexus cellphone and my Blackberry Playbook tablet both check for shorted D+ and D- lines.

I usually forget to generate a PDF so I will do so later today. Thanks for the reminder :D
Project logs / USB Wrapper
[edit] You can order it on my website at

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: ... 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.

The project is open source hardware and the sources can be found at http://

Here is a video I made today for USB Wrapper:

As usual, questions/comments/concerns/etc are welcome and appreciated. Thanks!
Project logs / Re: antiAFK
[quote author="dougal"]I hate to sound negative, but isn't the ATMEGA32U4 a bit overkill for this?

I did something similar last summer using a Digispark, which uses the ATTiny85. In my case, I used the DigiUSB library to emulate a mouse instead of a keyboard, with a small amount of movement to prevent the screensaver from activating.,1018.0.html[/quote]

Normally I would agree, I wanted to make it compatible with the Arduino Leonardo.

[edit] After taking a closer look at the project, I might be able to transition to using their bootloader and libraries for a future revision. Thanks for pointing it out.
Project logs / Re: antiAFK
[quote author="Sjaak"]The exposed pad is also used to dissipate the heat generated by the small IC. Mostly it is not electrically needed, but just thermocally (?). For prototyping you prolly get a way with it.[/quote]

True. Thankfully I'm not sinking/sourcing any real amounts on the micro so heat dissipation isn't a problem here.
Project logs / Re: antiAFK
[quote author="joeforker"]Tell me more about your hand-soldered VQFP, I am impressed.[/quote]

These were the first boards I soldered together that featured parts without exposed leads. I used my reflow/toaster oven, but I did not use enough paste for several of them. Thankfully, I had left plenty of pad exposed on the PCB. I applied plenty of flux and a small amount of solder to my iron. Just dragging over the pads then sucked up the required amount under the pins to make the connection. It went surprising well. In fact, you could probably do the entire board by hand without the initial reflow step so long as you do not require the center pad to be connected. Just make sure to leave enough exposed on the PCB to give you something to work with.