Projects | In Which Jarrett Builds

Archive for Projects

Jarrett | June 23, 2014

Knowledge is Power

After pulling apart a NDSL, I know a lot more!

Tracing out the connections, a lot of the LCD pins have a designator silkscreened on, which is totally awesome. I spent a bit of time tracing as many as I could, and then I internetted what I had. That led me to this amazing page, which has the rest of the pin names, but not a lot else relating to this. Totally rad information on other parts of the NDS and GBA systems, though.

Here’s the full(ish) pinout, according to Nintendo:

___NDS-Lite lower screen/lower backlight (P4)________________________________
  1-VDD-5 6-MOD    11-LD1xx 16-LD1xx 21-LD1xx 26-LD1xx 31-LS   36-GND
  2-VDD10 7-GSP    12-LD1xx 17-LD1xx 22-LD1xx 27-LD1xx 32-VSHD 37-COM1
  3-VDD5  8-GCK    13-LD1xx 18-GND   23-LD1xx 28-GND   33-GND  38-LEDA1
  4-GND   9-LD1xx  14-LD1xx 19-LD1xx 24-LD1xx 29-DCLK  34-xx1? 39-LEDC1
  5-VSHD  10-LD1xx 15-LD1xx 20-LD1xx 25-LD1xx 30-SPL   35-REV

That is actually pretty close to the datasheet I’ve been working from. My analysis of where the screens differed was pretty accurate, too, which is cool.

Based on that, here is the NDSL LCD pinout in order, probably, compared to the other one:

Pin	Nintendo DS Lite LCD	Sharp LQ030B7DD01
1	VDD-5	VDD
2	VDD-10	NC
3	VDD-5	MOD
4	GND	SPS
5	VSHD	CLS
6	MOD	NC
7	SPS	VEE
8	CLS	VCOM
9	R0	SPL
10	R1	R0
11	R2	R1
12	R3	R2
13	R4	R3
14	R5	R4
15	G0	R5
16	G1	G0
17	G2	G1
18	GND	G2
19	G3	G3
20	G4	G4
21	G5	G5
22	B0	B0
23	B1	B1
24	B2	B2
25	B3	B3
26	B4	B4
27	B5	B5
28	GND	VSHD
29	DCLK	DGND
30	SPL	PS
31		LP
32	VSHD	DCLK
33	GND	VSHA
34		V0
35		V1
36	GND	V2
37		V3
38		V4
39		AGND

The signals that don’t directly match the known datasheet are a guess, but usually a pretty good guess (eg. CLS on the datasheet is gate clock, and is in approximately the same pin area as GCK). I’ve gotta go back and check:

LS
xx1
REV
LEDA1
LEDC1
COM1

Figuring out the PCB footprint is also tricky from the component alone, and I made a couple mistakes in my earlier assumptions. Fortunately the PCB gave me a little more information, so this is the Nintendo DS Lite LCD connector. Which both gives me a datasheet, and a 50 cent source for more connectors instead of the Chinese manufacturers that market it specifically for the NDSL and charge $2. EagleCAD has a compatible library model from Omron with the model number “XF2C-3955-41A”.

For the touchscreen connectors, they’re 0.5mm pitch, four contacts. That’s a pretty common sizing, and it’s not even a good idea to use the same connectors. That thing totally disintegrated the first time I looked at it funny. A quick search turns up a decent replacement in both top and bottom contact versions, depending on where I want to mount the connector. Eagle part number “52745-0490” from Molex.

Category: Splice of Pi |

Jarrett | June 16, 2014

No comments

NDSL LCD FFC Design (OR: Working with an unknown TFT screen)

I like acronyms. They make me look smrt.

Designing a board to mate with the Raspberry Pi is pretty straightforward.

It’s mostly just a pass-through board. We need a footprint, though. As far as I know, there are no available PCBs out there that people have used the (nonstandard) Nintendo DS connectors on, so no footprints.

First we try the easy way: Asking the manufacturers directly.

That doesn’t work very often. Fun story: I once emailed an industrial control company looking for the models for some of their $5000 3-phase power supplies. Having the files would save me probably half an hour while laying out an equipment rack. Twenty minutes later, the customer support team emailed me the internal engineering model file. Complete with PCB model, populated with all components.

I really really don’t think they were supposed to do that. I thought it was pretty funny.

Here’s the LCD connector for the NDS screen. As you can (sort of) see, it’s 20 pins, and measured a little over 11mm from the first to last pins. With a connector that small, though, exact pitches are still hard to be sure about.
And it’s two rows of pins.

So we go through the Eagle parts libraries looking for something that might work. I kept my eye out for small-pitch 40-pin, double row connector footprints specifically, but I dumped a whole bunch of connectors onto the schematic that might work, after some changes.

Quick layout on the board, and…

…Print it out 1:1 and see what lines up. I used to think that footprint-measuring PCBs were dumb, but I think I’m coming around. Would save me a few minutes and a little printer ink.

The pins lined up with (one side of) the connector labelled XF3B-5145-31A. It’s a 0.3mm pitch Omron connector.

Good. Using that information, we draw up the new part, and Bob’s your uncle. I don’t know what that phrase means.

Side note: The LCD flex cable is pretty standard, and I may try and find an alternate connector in the future. For this, right now, I just wanted a known-good connector and design a PCB around that instead of ordering a big bag of assorted FFC connectors off Digikey.

After drawing the new library parts (touchscreen connector footprint, too, remember), I need to know how to connect everything. In this case, I have an LCD of uncertain properties, a Raspberry Pi GPIO connector of known properties, and a known resistive touchscreen.

For the touchscreen, it gives an analog value (more on that in a future post), so we’ll need an analog-digital converter to get the values to the GPIO. I’m thinking the SX8652 or AR1011, we’ll see. Digikey has them both inexpensively.

The TFT LCD is a little trickier. I wrote in a previous post that someone found a datasheet for the Sharp LQ030B7DD01 that looked similar, but now that I have the DS screen in my hands, I don’t think it is.

From what we can see right here, there are 39 pins. Good.

That huge plane that covers most of the top is probably ground, and is connected to pins 4, 18, 28. and 33. Not good. Assuming pin 1 is on the left, the pins don’t line up properly with any single node.

Even if I have any of the above assumptions wrong, the datasheet lists pins 10 through 27 as RGB data lines. Pin 18 must be independent.

If the right side of that image is pin 1 instead, the above problem still exists. There are only 39 pins on the datasheet, so it seems possible that pin 18, near the centre, could be designated as an extra ground pin, but there are 39 physical pins that correspond to that datasheet, so there isn’t really any wiggle room here.

On the right side of the picture, you can see pins 38 and 39 going to some large pads. Those loop around behind the visible flex cable, and then connect to that one you can see on the right. Looks like a backlight control, probably.

Anyway. Those are the reasons I don’t believe this is the right datasheet, but fortunately, there is a “Sharp” logo on the back of the screen. So I do have a starting point for finding a better match.

Going down the internet rabbithole, I found a German-language forum discussing the LCD, which linked to a now-defunct NDSL hacking site, which was conveniently backed up on the Wayback Machine at archive.org.

During that bout of internetting, I came across an antitrust lawsuit that Sharp was involved with, price fixing these screens alongside Hitachi. That means that both manufacturers were producing LCDs with the same pinouts, so that gives me another lead to a possible datasheet. But anyway, it’s probable that the Sharp LCD is LS030B7DD12F, which has no datasheets available online. The Hitachi counterpart is probably 49N07020132, same story.

I guess I need to actually track down a Nintendo DS Lite and really hack it. Damn.

Category: Splice of Pi |

Jarrett | May 26, 2014

No comments

I need another dev kit

Recently, I got given an FPGA development kit to continue working on my SHA1 system. The end-goal is to eventually integrate that into a PCI-E card, but we’ll see how that works out.

The FPGA kit I have is the Digilent Basys2, and it uses a Xilinx Spartan 3E chip. The lowest-tier, 100k gate model.

I’ve updated the current code, here, consisting of the parallel behavioral SHA1 implementation, a serial input wrapper that parallelizes the data and acts as an interface, a simulation testbench, and a physical testbench specific to my board. Unfortunately, this code, which is the absolute simplest building block of the final project is about 600% too large for my dev board. It takes up about 12,000 logical slices, and the Spartan 3E version I have only has about 2,000. For further reference, a Papillio Pro, which is very popular right now, uses a version of the Spartan 6 family that has about 9,000 slices.

My goal right now is to, without spending a whole lot of money, to get a development board, or even a bare FPGA on a breakout board with at least 15,000 slices so that I can benchmark this implementation of the algorithm. After I do that with the first iteration, I can write a concurrent version, benchmark it, and start tweaking. I’d really like to get into low-level optimization.

Stretch goals involve getting a massive FPGA to do a lot more with, but those can start to run upwards of $150 just for the chip alone.

I don’t even need to keep these boards, I just need to use them briefly as a proof-of-concept.

Category: SHA1 |

Jarrett | April 14, 2014

No comments

Further adventures of implementing SHA1 encryption on an FPGA

A few years ago, I designed and simulated a SHA1 encryption machine using CMOS logic. I actually built everything using Altera’s FPGA tools, Quartus. With standard propagation of the 7400 series, it worked out to about 1.8MHz max clock speed to prevent race conditions.

Implementing the system right in VHDL and running it on the FPGA itself, I think I can get it faster. The previous system also relied on a serial workflow that limited the data to one hash at a time. If I parallelize everything, I can likely get it up to 80 time faster. A very very cursory look suggests that SHA1 has been done a million times by a million different people, but I’m not looking at their work. This isn’t about them.

After trying to figure out how I figured out the SHA1 protocol last time, it looks like the only document I used was the original RFC 3174 spec. There are a lot crappy pseudo-code and diagrams out there, but man, that paper is just so well-written, nothing compares.

I also found an old spreadsheet in my Drive account in which I’d written out the first few rounds of the hashing process.

Initially, because I’m relearning the algorithm at the same time that I’m relearning VHDL, I implemented it completely sequentially. The project is here. It’s a proof-of-concept, not actually something that is usable, at the time of writing. It will likely evolve into something cool.

Category: SHA1 |

Jarrett | March 24, 2014

No comments

Vroooom

There isn’t really any story behind this.

I have a joystick module, and it would be pretty simple to hook it up to a motor and use it for a remote control car.

I decided on a few parameters:

No microcontroller. Where’s the challenge in that?
Joystick wired directly to the car. Wireless can be a stretch goal, this is supposed to be a really quick project.
Front/back on the stick will drive 12v DC motors with variable duty cycle PWM for speed control while keeping torque high

This is a reasonably complicated analog circuit, and I really do prefer to simulate my numbers when I do that, just to make sure that I have a valid starting point for real-world tweaking.

I’m not really that keen on diving into SPICE (especially LTspice, which would be my only option, at the moment), but a cursory Internetting around came up with CircuitLab. Now, I’m not normally one to plug some commercial service without very good reason, but this service is seriously pretty great. It’s an online, cloud-based schematic editor and simulator.

I’ve been playing off and on with online services for five or six years, but really nothing has been any good. But this one is really intuitive, free for non-commercial use, and they don’t even nag me about buying anything, even after detecting that I have an adblocker.

But anyway. I may or may not build this, it was mostly an op-amp and 555-hysteresis exercise.

Here’s the first stage, with a potentiometer(R5) controlling the op-amp output voltage. Varying the voltage adjusts the control voltage that the capacitor is allowed to charge to, causing the output duty cycle to change.

Here’s a steady-state simulation of R5 low, PWM output (and therefore DC motor speed) low:

R5 high, PWM output high:

Perfect.

That’s only half the battle, though. I need to get two inverted PWM signals coming off a single potentiometer, centred around the middle.

Part of the challenge of that is that you can’t just duplicated the above circuit. When the pot is involved with both high side(for controlling forward) and low side(for backwards), the circuits are somewhat in parallel.

Some small resistors to ground where needed to mitigate that. Eventually, I got a gorgeous graph that looks like this:

The important takeaway here is that the output voltage at the joystick-centred position is effectively nil for both sides. Each one respectively ramps up when the potentiometer is shifted to their side.

The 555 output stages aren’t in this simulation because they don’t change from the first circuit.

Here’s the second circuit:

The low-side 555 circuit isn’t shown either because again, doesn’t change.

A couple more notes:

I’d actually be driving this circuit with 12v, but capacitor charging rates are all relative, so the timing wouldn’t change.
Those two resistors to Vcc and GND, R6 and R9 are to adjust the joystick trim.
CircuitLab actually has excellent export options, too. I didn’t use them because I like the gridlines.

Again, this project is mostly just a fun simulation exercise. If I’m ever really hard-up for something to build, I’ve got everything written down here so I can do it. That may never happen, though.

Category: DC Car |

Jarrett | March 20, 2014

One comment

Clearing out the backlog

A couple years ago, I started work on a timelapse camera module. I built one board, came up with some corrections, and designed a better version. Then it stagnated for quite a long time.

A few months ago I checked over the files again and sent them off to a fab shop.

After the new boards arrived, I couldn’t find a local source for some of the components I needed and it sat for a long time again.

A few days ago I found some components that would also (mostly) work, so I started the project up again. Let’s get ‘er done.

The goal of the project was to be able to hook into any 2000-era tiny resolution digital camera and take a picture at set intervals. It’s powered by USB, and regulated down to 3.3v that most cameras use. There’s a very simple 7-segment-display-based interface with which to control the timelapse interval.

It’s powered by a PIC microcontroller, and the display is driven by a couple 74HCT164 shift registers by TI. The “HCT” portion of that is key, because these are both wide-voltage range (to be able to run off 3.3v), and fast enough to clock 8 times without visible flicker.

Here’s where I’m at right now:

I don’t have the 3.3v regulator that I designed for, but I found a different one that is adequate, with some bending of pins. None of my capacitors are the right footprint, and I don’t have the right resistor network package. All of these parts are pretty easily available off Newark/Element14, so I’ll have the appropriate parts for my second prototype.

Other than that, it looks pretty good. Keep in mind that I designed this version over a year and a half ago. I’m in a very different place now. Here’s what I would do now (or will do for a redesign):

I’ve mostly sworn off resistor network packages.
I realize I should have added a couple more decoupling caps.
I prefer to use SMD to DIP now.
With surface mount, I could also make this whole board much smaller.
USB-A male-male cables aren’t really common anymore, it would be much more convenient to use a microUSB port.
Driving the camera inputs would probably be safer with a transistor instead of directly from the PIC.
I need mounting holes.

I’ve rewritten the software. It stores timer values in EEprom and uses an interrupt to trigger the camera. At a later date, I’ll add in sleep settings for power saving, and control the camera on/off state for the same purpose.

For the interrupt, I want it triggered about every second. It triggers every time the 2-byte Timer1 register overflows. With the maximum prescaling dividing the clock (and register) to one second, I’d have to set the clock speed down to 1MHz. That slows down other parts of the program, enough to make my software-SPI-controlled display have visible flicker. That’s not cool.

To get the proper time, then, I need to count off a bunch of interrupts until I get to 1 second. I’ll calculate a good set of values for Timer1 to do the necessary.

Fosc / 4 = 1MHz

1MHz / 8 prescale = 125kHz

Period = 1 / 125kHz = 8ms

1s / 8ms = 125000 clocks

Say, 125000 / 2 = 62500 clocks

65536 clocks before overflow – 62500 = 3035 starting value (and decrement seconds every other interrupt)

After measuring against a stop watch for two and half minutes, it’s about 3 seconds too fast. That’s 3 / 150 seconds, or about 2%.

So change the starting value to 3035 * 1.02 = 3095.

I’m using the internal oscillator, which tends to be pretty inaccurate. That’s okay, I can tune it. A good way to do that is to take timelapse photos of a clock when I’ve put everything together. I’m curious how much it’ll drift after I calibrate it due to time or temperature. It’ll be an experiment.

Pictures of the build process to follow.

At first, I was lamenting not having proper mounting holes on my PCB. After examining the chassis I had lying around, though, this is perfect. The ribbed interior can hold slices of acrylic, and, properly cut to shape, they’ll sandwich both of the boards, the 7-seg display, and the lens assembly exactly where they need to be. No fasteners, and no unnecessary holes. Perfect.

Category: Elapse |

Jarrett | January 10, 2014

No comments

Gears gears gears gears gears

After moving again at the beginning of December, I’ve realised that I’ve built a lot of things, but nothing could really be called pretty in the conventional sense. There’s a lot of room in my new place, and I need something I created to display. Visitors should be able to come into my house (after being invited, please) and say, “Oh hey, that’s a cool x, where did you get it?”

Yeah, I don’t have anything like that

It’s time to change that.

I built a clock. I have a working version of all the mechanics down. It moves like a well-oiled machine. Well, more like an unlubricated wooden machine. Because, you know, that’s what it is.

Pictures!

: Early prototype

: Centre movement

: Assembling

: Minute hand on the outside

Right now I’ve built a quick motor-running test board, and I’m starting to design the rest of the electronics. Pretty soon, I’ll be drawing out an exploded-view diagram, and I should be able to package this as a kit. We’ll see what happens.

I’ll have video up soon.

Problems right now:

I’m using old HD motors because I like the short form-factor, but early tests are pointing to them not being powerful enough.

I’ve got three avenues for solutions, I’ll do some analysis and report back.

Category: Clocks |

Jarrett | December 15, 2013

No comments

Closing the Loop

Here is the motor that I’ll be using. I don’t know if I mentioned this already, but I’ve got a big bag of these things. I don’t know where they originally come from, and I can’t find any sort of datasheet or description on the internet.

But that’s okay. I can work around that. I didn’t even know what kind of motors they were until I poked around with a multimeter. Turns out they’re brushless DC motors, which is pretty cool for both accurate positioning and speed, but relatively difficult to control.

Here’s the pinout, from left to right:

Winding A
Hall Effect sensor A
Winding B
Hall Effect sensor ground
Winding C
Hall Effect sensor B
Hall Effect sensor power
Hall Effect sensor C

Finding the windings was easy, I just checked the resistance between pins. My highly sophisticated method for finding the sensor pins, though, was putting a voltage across them and watching for smoke. I guessed wrong the first time, so, uh, make that three motors I’ve sacrificed, all told.

The output on the Hall sensors(powered by 3v) are very low, so they need to be hooked up with a differential amp to a potentiometer. The motors draw about 800mA at full load.

Because I have a whole bunch of these motors, I’ve been doing research for the absolute cheapest way of controlling these. Most of the controllers chips I’ve found are right around the $15, which is ridiculous.

So I built a quick test protoboard because it was cleaner than a breadboard, but it ended up getting a little complicated.

How I’ve got it right now:

: Closed loop BLDC motor control

While building this, I finally found an affordable solution, the MC33035. It was about $2. But hey, at least I’m intimately familiar with these motors in a way that a one-chip solution wouldn’t give me, right?

Here’s the test-code for PIC that I wrote. I still have maybe 30 of these motors, so they definitely could come into play in future projects. So, one-chip solution aside, I’d add forward/reverse control, PWM speed, and potentially speed/position feedback so I could include a PID loop. That would be pretty cool.

#include <htc.h>

//Int osc, wdt disabled, mclr disabled, bor, fscm
__CONFIG(0x3F1B);

#ifndef _XTAL_FREQ
 #define _XTAL_FREQ 96000
#endif

//HALL EFFECT

#define PHALLA RA0
#define PHALLB RA1
#define PHALLC RA2

#define SENSEA RB5
#define SENSEB RB4
#define SENSEC RB3

void forward(void) {

    //AC', AB', B'C, A'C, A'B, BC'
    if(PHALLA == 0 && PHALLB == 0 && PHALLC == 1) { //Step 1
        PITCHA = 1;
        PITCHC = 0;
        ENB = 0;
        ENA = 1;
    } else if (PHALLA == 0 && PHALLB == 1 && PHALLC == 1) { //Step 2
        PITCHA = 1;
        PITCHB = 0;
        ENB = 1;
        ENC = 0;
    } else if (PHALLA == 0 && PHALLB == 1 && PHALLC == 0) { //Step 3
        PITCHC = 1;
        PITCHB = 0;
        ENA = 0;
        ENC = 1;
    } else if (PHALLA == 1 && PHALLB == 1 && PHALLC == 0) { //Step 4 
        PITCHC = 1;
        PITCHA = 0;
        ENB = 0;
        ENA = 0;
    } else if (PHALLA == 1 && PHALLB == 0 && PHALLC == 0) { //Step 5
        PITCHB = 1;
        PITCHA = 0;
        ENC = 0;
        ENB = 1;
    } else if (PHALLA == 1 && PHALLB == 0 && PHALLC == 1) { //Step 6 
        PITCHB = 1;
        PITCHC = 0;
        ENA = 0;
        ENC = 0;
    } 
    SENSEA = ~PHALLA;
    SENSEB = ~PHALLB;
    SENSEC = ~PHALLC;

}

void main(void){
    ADCON1 = 0x07; //disable ADC
    CMCON = 0x07;
    TRISC = 0x00; //Port C Tris output
    TRISB = 0x00; //Port B Tris output
    TRISA = 0xFF; //Port A Tris input 

    while(1){
        forward();
    }
}

Edit, 6/12/2017:

It’s very weird to see something from legitimate sources start to appear as grey market goods, several years later.

I came across this and this item on AliExpress.

In case those links disappear (likely), it’s billed as: AIYIMA 2pcs Micro DC Brushless Motor 22MM Planetary Gear Motors External Rotor With Hall. The markings on the visible label read 4086013, 172336, and XF08F4901147. On the product page itself, the motor claims to be a AIYIMA-A4F321. The markings on the version I have, however, read 15246014, 172289, and XF04B4000507. Hopefully that helps someone.

The first link is a plastic shaft version I haven’t seen before, while the second link is the metal version that looks identical to my own.

Category: Relapse |

Jarrett | November 23, 2013

No comments

Pie-faced

There’s a new tool on the block, you might have heard of it. They call it a Raspberry Pi, and it’s neither infinite, nor raspberry-flavoured (I checked).

It’s a System on a Chip, or a tiny computer.

A big part of its selling point was that it was $25. This kinda got shifted up to “yeah, $25, but $35 for the really useful one, and then with shipping you’re probably not going to see one for less than about $45.”

So the economy aspect got lost a little bit. People started selling $20 cases, and $150 screens, and I think it’s all a little ridiculous. I’m not using it to replace my desktop computer here.

The beauty of an inexpensive and highly portable computer is that you can give it one task, set it, forget about it, and just go buy another one when you want to play with the platform again. You don’t need a large screen for that, usually.

With all of that in mind, I set about looking for the cheapest LCD I could find. I ended up with a replacement screen for a Nokia N77 cellphone. It costed $4.75. A little more research, and I even found someone who was driving them with an Arduino, and that’s most of the battle. The only problem is that it uses a hard-to-find proprietary connector. So that sat on the back-burner for a while.

Recently, an eminent change-of-address has spurred on a new project. And, suddenly, I need a small LCD again. After doing some re-evaluation, I’ve changed tack somewhat.

I’ve decided to go with a Nintendo DS Lite screen, and here’s why:

You can get a digitizer to add touchscreen capabilities.
It’s only a modest price bump. About $8 for the screen, and $1.50 for the touchscreen.
They are far, far easier to consistently be able to source from eBay or any number of repair shops.

So I just pulled the trigger on that. While waiting for my shipment to arrive, I poked around for what other people have done with them.

Plenty of people have gotten the touchscreen to work with Arduino, PIC, and Windows. From what I understand, it’s just a couple of potentiometers.

No one really has any information about the LCDs, though, which is strange. Eventually I found a datasheet (via this guy) and an RPi framebuffer driver project. The DS screen isn’t on there, but the datasheet looks pretty straightforward.

I guess I’ll find out when it gets here.

Category: Splice of Pi |

Jarrett | November 6, 2013

No comments