Adafruit 16×32 LED matrix on Arduino Due (4)

I’m finally making some progress with introducing a higher color depth. Using BCM I’m now more or less on a 12-bit color depth. In the Adafruit driver I found parts of code that first were not very clear to me. There are methods like Color888(uint8_t r, uint8_t g, uint8_t b) and Color333(uint8_t r, uint8_t g, uint8_t b) but than I found that these are actually related to how colors are kept in memory bit wise. You see, with 333 colors you’re using 3 bits for the red value, 3 for green and 3 for blue. So this means there is a total bit depth of 0…7 for each RGB value resulting in a total 9-bit color depth which gives us 512 colors. 8/8/8 colors are 24-bit large in total and are the so called True Colors. They’re often used on PC’s in results in different colors. The 5/6/5 colors, also called High Colors, are 5+6+5 = 16 bits wide and result in 65536 different colors. This is also often used on computers. The awkwardness here is that the green portion has one bit extra compared to the red and blue portion. This is done because there was otherwise one bit unused (better to use it right!) and because of our perception is green is different that for red/blue one bit extra for green would be best suited (don’t ask me the exact scientifical reason, look for it on wikipedia). This 16-bit color depth is also used for storing images in the Adafruit driver. But so far it’s used only for storing, to display these images the driver falls back to a 12-bit color depth in 4/4/4 format and this because of two reasons. More colors would be kind of hard to do because it would dramatically reduce refresh rate and this you certainly don’t want. Although LEDs are used, refresh rates in between 25 and 50MHz are still not high enough for the human eye to experience the display as smooth. So it’s better to stuck at 12-bits deep. Also, in the 5/6/5 setup, if you use BCM modulation, there is one moment where you’ll be displaying only the green portion because red and blue are not equally in bit size.

But BCM, what is this exactly. BCM is a modulation technique like PWM is. With PWM you define the percentage of on and off time. Say you’re having a pulse of 70% on and 30% off during the total period, if you have a LED connected to that pulse you’ll experience it as slightly dimmed. With BCM you’re not giving any percentages, you’re using the bit value instead. Let’s say you’re using 2-bit BCM, for this the 2 bits are divided over the total period and so the more ‘1’s you have in your binary BCM value the more the LED will be pulsed on during the period, and the brighter it will look. Let’s say you’ve the value 11, the LED will be set on for the total period of time and will look very bright. 00 means it will be off all the time. But what about 01 and 10? Well, here the bit-value comes into play otherwise both codes would result in 50% on and 50% off. Using the bit-value the ‘1’ in ’10’ has a higher bit value than the ‘1’ in ’01’ and so it will stay on longer depending on the weight of the bit. There is a nice introduction to BCM found here.

And so the Adafruit driver uses 4-bit BCM, using only the 4 most significant bits of their 16-bit (5/6/5) representation in memory. I’ve gone the same direction and got it more or less functional:

This lowres picture doesn’t exactly show you a lot, I’ll have to look for better photo footage. The higher color depth is now possible using BCM but it’s still not finished yet. Resetting the timer each time kind of screws up the refresh rates so instead of using the due timer library I talked of before I’ll have to write the timer code myself and cut off an overhead. Also I noticed that I’m doing a lot of digital writes (6) to set just the RGB pins, where in the Adafruit driver they can set all 6 pins altogether. If a could do this it would also greatly reduce the timer interrupt time and allow me to bump up the refresh rate. So, more work ahead…

About Arduino’s DigitalWrite – Adafruit 16×32 LED matrix on Arduino Due (3)

In the previous article I already noticed how the display was starting to get less bright when I bumped up the refresh rate. Reading some parts of the Arduino Uno driver I noticed this one comment hinting to the slow Arduino DigitalWrite function. I never knew or red about this function not being very fast, I was expecting maybe a little impact but not as much as described in some online articles. And so I began to think of also looking for a way to faster manipulate pin outputs so that the driver works faster and better, and maybe allow us to do more than before. For Arduino Uno there is tons of information to find, however for Due you have to look a lot better. On the Arduino forums however I found this thread where faster port manipulation code has been presented:

inline void digitalWriteDirect(int pin, boolean val){
  if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
  else    g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;
}

inline int digitalReadDirect(int pin){
  return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);
}

void setup() {                
  pinMode(13, OUTPUT);     
  pinMode(12, INPUT);     
  Serial.begin(9600);
}

void loop() {
  digitalWriteDirect(13, HIGH);   
  delay(1000);           
  digitalWriteDirect(13, LOW);    
  delay(1000);          
  Serial.println(digitalReadDirect(12));
}

In my current driver I swapped all digitalWrite methods with the digitalWriteDirect methods from above and than compared how fast writing one (double) row of LEDs goes. Time was measured by calling the micros() method before and after writing on row of data, taking the difference of both and next report back by doing a single Serial.write(). Here is a comparison:
digitalWriteDirect: 91us
digitalWrite: 661us
So as you can see the direct implementation gives us nearly 7 times better performance, or the other way around I kind nearly draw the entire display this time where before I could draw only one row. I also now noticed that in my display only the last rows of each half screen were illuminating very bright while others where nearly not illuminating at all. The reason is because now we switch so fast from one row to the next that the HIGH time of the pixels in a row is very small compared to before when using the slow Arduino implementation. The reason why the last row was however bright is because it get’s drawn as last and from here on it takes nearly 5000us before the next interrupt is being called, so it is really obvious that it was appearing really bright. In my last update I changed to drawing only one row per timer interrupt. This way rows get painted on a steady time base, and with using the faster digitalWriteDirect method we can easily bump up the refresh rate of the display so now the interrupt routine gets called 8 times more than before.
Next problem I get is that I need to call the interrupt code each 1250us in order to get a steady image. That is a 800MHz refresh rate per pixel row, and so 100Hz for the entire display, which kinds of bothers me because now interrupt code will interrupt normal program flow a lot of times, and I’m still at only 3 bit colors and I don’t have any support for dimming. I guess there is more reading ahead of me…

Adafruit 16×32 LED matrix on Arduino Due (2)

Not to much time spend so far on this display, but before I continued I wanted to make sure I can make the display illuminate asynchronously with the rest of the program flow. To do this we need to use interrupts which is launched after a certain timer expires. This way we can for example make sure that every 5ms the pixels are refreshed so that we get a clear non-flickering image. This also allows us to program our normal program code in the loop method without having to worry about the display code not being called in time (because then the display would go black for some time). For Arduino Uno the code is already there in the IDE to use, for Due a guy named Ivan Seidel already did some testing and programming and so we can also make use of interrupts on Due really easy (library on https://github.com/ivanseidel/DueTimer).

Here is a 3-bit colors version of the British flag displayed with the Adafruit 16×32 RGB LED matrix and Arduino Due.

I notice though that the LED’s do not really shine so powerful as they should, and also altering the interrupt timer to display at 50 or 100Hz intervals really ruins the picture (also this I can not explain). So more work ahead… may God save the Queen!

Adafruit 16×32 LED matrix on Arduino Due

Beginning of January I saw a video demonstrating a clock which also plays Game of Life during displaying the clock. This so called Clock of Life uses the Adafruit 16×32 LED matrix and a Arduino Uno microcontroller board. I never came across this LED matrix before but it seems like a nice and popular display to tinkle around with, so off course it was only days later that I owned my own copy of it. As far as the clock goes, I’d very much like to achieve using it as a clock too, but the Game of Life option I’d like to skip, instead I want it to be wireless connected to the internet so that NTP servers can help me keeping the time more or less correct and thrust worthy over longer periods of time, maybe even years. With this wireless connection of course come a lot more possibilities, like setting a alarm clock to wake you up by using your smart phone, set background images and let the user configure the clock remotely. Well off course there is lots of more features I could add, but let’s not start to think to wide before we can even get it working.

For the wireless connection I opted for using the Adafruit C3300 Wifi adapter. After receiving both this unit and the 16×32 LED matrix I noticed that combining both on a Arduino Uno was going to be pretty hard on pin usage. Furthermore I was also not very sure how processor intensive everything combined was going to be, and keeping in mind I might want to add even more features I opted for a more speedier and advanced solution: the Arduino Due. It’s a 84MHz processor with a lot more in- and outputs. First thing I did back in January was making sure NTP server requests indeed do work using the C3300 on Arduino Due as a standalone solution. Next: make another standalone version where I test the LED matrix, but it was then that I noticed the Adafruit 16×32 LED matrix is currently not supported for Arduino Due. Nooo!

After some googling I found out the display does take quite some processing power to display full colors. Some of the code has been really optimized for using the Arduino Uno/MEGA internal functionality. So it was more or less at this time that I started to notice this project was going to take a lot more time since I’d be writing the display driver myself. The Adafruit tutorial tells you some of the details of how the boards works, and if you read it very carefully you’ll notice it’s not so very difficult to do some basic stuff like lighting some LED in either a red, green, blue or white color, or not light it at all. However, for mixing colors and dimming the display more advanced programming is needed. But first something about the display.

Without getting to much into the details on how the display works electrically here are the available pins we should take care of:

A, B, C => row address select pins
R1, B1, G1 => red, green, blue led on/off pin of a pixel of an upper row
R2, B2, G2 => red, green, blue led on/off pin of a pixel of an lower row
CLK => clock pin
OE => output enable pin
LAT => data latch pin

For the display to work you’ll have to send data at a constant rate as the display itself does not have any memory. This implies a lot of other stuff which I’ll get into more detail later. The A, B, C row address pins (3 pins = 3 bits) allow us to select 8 different addresses. For each address not one but two rows are being selected. So setting the bits for address 000 does not only select row 1, it also select another row being it the 9th. The 9th and not the second, because it allows to have less scan rate. For each row we have 32 pixels, so with 2 rows selected each time we set an address we now have 64 pixels available to manipulate (where each pixel has 3 LEDs, for red, green and blue color). Setting the pixel color however happens in a serial way, first one has to set a appropriate signal on the R, G, B pins, but because we have 2 rows selected at the same time we also have these R, G, B pins twofold. R1, B1, G1 for pixels in the upper region, and R2, G2, B2 for pixels in the lower region. Next the CLK (clock pin), LAT (data latch pin) and OE (enable pin) should be used to send the RGB LED’s On/Off state for each of the 32 pixels per line in a serial way.

While this might not seem to complicated to understand, there is more than meets the eye. For drawing in either red, green, blue or white colors it’s as sample as setting only the correct bits at the RGB pins, though when one wants to set a yellow or purple or any other color more complex methods will be needed because we have only 3 bits per drawing cycle to our disposal. We will have to fool our user by setting a pixel first red, than blue, than red again, than back to blue, … nnd this very quickly so that for the user the different colors mix up into something that might look like purple. So let’s say with 3 bits we can have 8 colors, 2 drawing cycles would make 2 times 2 bits resulting in 6 bit color (= 64 colors), and 3 cycles would result in 9 bit color which represents 512 colors.

But it gets more complicated. What if we want to dim our display? We not only need to mix for the correct color, we also need more drawing cycles for PWM dimming the display (if the goal is to implement it). So Let’s say we mix to get to the correct color in 3 drawing cycles, we’ll probable need another 2-3 drawing cycles where all LEDs per pixel or not illuminating to get to the a 50% duty cycle. This however is a layman implementation because not all colors are evenly bright. Red for example requires only one LED, while white requires all LEDs to be illuminating and thus the white color will always be a lot brighter the full red. For this and other technical difficulties I did not yet think of I still need more time to work it out, for now I can only show you some basic code where the Arduino Due is used to show 3 bit color on the Adafruit 16×32 LED matrix:

Huawei G525

Although I’ve tried to avoid smartphones, as IT’er and programmer I found it however a necessity to own a type of smartphone, just for the hence of owning the technology and better understanding what benefits it may have. And so I got the Huawei Ascend G525. The phone is okay for the price, battery life is not super but when you create a “Dumphone” profile it can easily survive few days without recharging. However, I found it for example very useful to have GPS navigation on board, but unfortunately there was no phone dock available where I got my phone and so I quickly got to the idea to make one myself using 3D printing. I’ve never tried 3D printing myself so it’s a good practice, but it does not necessarily mean it’s going to be cheaper or better. In the end it does in what it needs to do, it costed me about 20€ and I very much liked the concept of just drawing something that can be of good use. Here is the result:

Dell E4300 BIOS hacking

I just got my hands on a 2nd hand Dell Latitude E4300 laptop previously owned by the Belgian Ministry of Justice. The computer has a functional Windows license on it, however the computer is currently configured in a Administrative Domain so any normal users that could possible log into this machine is not allowed to install any software. Furthermore, since I didn’t have any user credentials I was forced to find a way to bypass the AD user login. Linux gives us some possibilities, however since the BIOS is locked by a administrative password I was not able to select or change any other boot device aside of the hard drive. One solution is to unscrew the hard drive and install it into another computer where you do have the boot options available. However, bypassing the BIOS admin password is not so hard either on these machines and requires just some googling…

To get into the administrative password protected BIOS, first press f12 during system boot to get into the E4300 BIOS. You’ll notice the unlock button at the bottom. Press it and you’ll be asked for the admin password. You can however obtain the master password from the following website: http://bios-pw.org/, enter your serial number (might look like this: 1234567-2A7B), and use the password that is given by “Dell by serial number”. So in the BIOS, press the unlock button, next enter the password and press ctrl + enter and now you should get into the unlocked BIOS. One remark here: the password should be entered on a QWERTY keyboard, for AZERTY keyboards you’ll have to convert your password to a QWERTY string. So, if for example you get the following response from the BIOS-PS.ORG website: “Dell by serial number: hTfn7Xz3yWqg8”, then you should enter “hTfnèXw”yZag!” on a Belgian AZERTY keyboard. So the trick here is to enter numbers without using the shift button as you’re used to, switch “q” with “a”, “z” with “w”, and “m” with “,”.

Now, make yourself a LINUX life boot cd, mount the windows drive and save whatever data you wanted to safe. Good luck!

Opel/vauxhall Vectra C 1.9 CDTI (Z19DTH) engine overview part 2

Continuing on what I wrote few days ago, here is part 2 of the Opel/Vauxhall Vectra C 1.9 CDTI (Z19DTH) engine overview. Some of the most common things were already pointed out, in this article I’ll add a few more.

For starters, the glow plugs:

The glow plugs makes sure that the fuel burns when starting the engine, afterwards they’re no longer needed with diesel engines. Here is a more closed up shot:

Be carefull if you’re thinking of replacing them, they can snap quite easily. It’s good to already add some lubricant few days before you’re going to remove them. The biggest part of the glow plug is however hidden inside the engine and is not visable on the pictures above. In total, they look like this:

The big iron tube you see on top of the engine is the common rail:

Commen Rail schematics:

In the following video there is a good explanation about the common rail system in modern diesel engines:

In this video they also mention the swirl flaps. These flaps are located inside the intake manifold, but can sometimes be a source of error. Since using the EGR system involves reusing exhaust gas, the EGR valve and intake manifold’s swirl flaps might block or get damaged because of dust particles that stick around. A good tip is to check the EGR valve once in a time and clean it (does not take a lot of time since it is easily reachable). Alternatives is to block of the EGR valve so that no exhaust gasses are used anymore. On the internet you’ll probable find some blanking plates, but you can also make one yourself:

Aside of this you also might want to check the boost (MAP) sensor as it is also located in the intake manifold and so it will take a lot of dust too. The boost sensor sits close to the EGR valve:

The sensor itself might have a lot of dirt on it, so cleaning is advised:

The boost sensor, also known as MAP (manifold absolute pressure) sensor, measures the air mass flow rate. The ECU can then take the exact fuel amount to make a optimum combustion.

On the front of the car there is also the MAF sensor, located just next to the intake air filtering box:

The MAF (mass airflow) sensor senses the mass airflow of air being brought to the turbo. It may also be a source of problematic engine behavior, although it occurs less than malfunctioning EGR valves for example.

Opel/vauxhall Vectra C 1.9 CDTI (Z19DTH) engine overview

My previous article teached you something about modern car emission control systems. In this article I will explain you through a series of pictures how these are implemented in the Opel/Vauxhall Vectra C 1.9 CDTI with Z19DTH engine code.

For starters let’s have a look at the front of the car with radiator, intercooler and airco heat exchanger removed:

The engine block itself can easily be noticed central in this picture. The air intake is at the left side in this picture next to the front light, from there on the air flows into the air filter and back out into the turbo which is the brownish rusty thing also at the center of the picture. The turbo uses the exhaust gas to spin up and so it is fixed onto the exhaust gas manifold. The exhaust gas manifolds collects all the exhaust gas that has been created inside the engine due to the burning of air and fuel. It collects it and brings it to together and then runs the exhaust gas to the turbo which will spin up at the exhaust side and at the air intake side (because both compressor wheels are physically connected). And so the intake air will get compressed which allow for more air inside the engine and so more fuel to burn which increases the engine performance in general. Another shot of the front of the engine:

Here is another shot of the turbo mounted onto the exhaust manifold:

The EGR (exhaust gas recirculation) system for the Z19DTH engine takes exhaust gas from the exhaust manifold. In the above picture you can clearly see the bigger hole on the right side where some of the exhaust gas will be collected. The picture before also has an indication where this hole is located. So, some of the exhaust gas will be used to drive the turbo, other remaining exhaust gas will be reused in the EGR system. From that particular hole that I just described, the exhaust gas flows through the EGR cooler and back into the air intake system. The EGR cooler is cooled be the same water that cools the engine, and looks as following:

From exhaust manifold to intake manifold:

In real life:

In the above picture, the thing next to the EGR cooler is the EGR valve. The black part of the valve is the electronics to drive it. Inside the iron housing there is more or less a small iron bar which will control the valve and make it possible for exhaust gas to either be mixed with the compressed intake air or not used at all. The EGR valve sits on the back of the engine where there is the intake manifold.

The intake manifold is where both EGR’ed exhaust gas and compressed intake air flow together. The intake manifold will guide the mixture inside the engine where it is used for burning fuel. Another view at the back of the engine:

Here is what the intake manifold looks like separately:

In real life:

And so air travels inside the inside, helps burning the fuel and leaves the engine again through the exhaust manifold, to either be reused again for driving the turbo or for the EGR system. For today that’s enough details, more later!

On dust particle filters and exhaust gas recirculation

Modern Diesel cars come with a lot of tricks to either boost the car performance or suppress the car emissions to meet the norms. There is the turbo for example which simply increases the amount of air inside the engine by compressing it, and thus increasing performance. But there is also the dust particle filter (DPF) which filters the exhaust gases which results in lower exhaust dust particles and the exhaust gas recirculation (EGR) technique which reduces nitrogen oxide emissions. However, there is a few concerns about using the latter, and since every new diesel car comes with such exhaust filter it is best to inform you what consequences it will bring before acquiring a new car.

For starters there is the exhaust gas recirculation (EGR) technique which is used to reduce NOx emissions. The system works as following:

In any normal turbo driven engine the intake air is being compressed by a turbo lader. The compressed air is optionally being cooled by an intercooler and then used inside the engine to burn fuel and make the engine run. The exhaust gases (that are being created by combustion of fuel and air) leave the engine block through the exhaust manifold where afterwards it will be lead back to the turbo lader. This will bring the turbo lader to a spin and so the intake compressor wheel of the turbo is also being moved which will result in compressed air, more air inside the engine and thus higher performance. In the end the heated exhaust gases will flow through the exhaust pipe back out of the car.
With the EGR technique, the exhaust gases will be used again, not only to drive the turbo but also as intake air. Notice in the picture above how in between the turbo lader and engine block (exhaust manofild) the hot (red) air is also flowing back inside a EGR cooling pipe (notice the recirculation gas tag) and then back to the engine. The reason this is being done is because the engine produces quite some nitrogen oxide (NOx). Bringing the low oxygen exhaust gases back to the car reduces the combustion temperature which on its turn reduces NOx (and also a little bit of performance) because NOx is created at higher temperatures.
From a environmental point of view, this is a good thing, since now a lot less NOx is left, however the technique has some mayor drawbacks and for diesel engines this also led to a higher need for a dust particle filter. Aside of lowering NOx emissions, EGR also lowers the combustion efficiency leaving more fuel not to burn, and creating more carbon and particle matter. Because of the extra carbon emission, a DPF comes to help.

The dust particle filter itself is not so different from any other filters: it catches the particle matter from leaving the car. The pressure sensor notices when the filter get clogged up, once a certain target percentage of pressure loss is met the car will regenerate the DPF by burning the clogged up carbon that is left inside the DPF, effectively cleaning it again. One of the reasons why diesel engine or not fitted for small trips is because the DPF never gets the chance to properly clean itself because regeneration sometimes takes up to 15 minutes, and only starts when the exhaust gas has reached a certain temperature.

The DPF should not be mistaken by the intake air filter which is positioned in front of the car, and looks like this:

The DPF looks more like the following picture and is positioned beneath the car, nearer to the exhaust pipe:

Some helpful information can be found for example in this small article: http://www.theaa.com/motoring_advice/fuels-and-environment/diesel-particulate-filters.html

Data conversion

Minor update on the ELM327 OBD scan tool:

A GUI has been added that is auto used when a graphical environment is available, otherwise the program will fall back to console usage. GUI does not contain any usefull controls yet. Users can also force console interface by adding the application launch parameter “-c”. I’ve scanned some of the more convenient PID codes on the Vectra and here and there I’ve also implemented data conversion to make it easy readable. Here is some console output:

PIDS_01_20_SUPPORTED: 01,04,05,0B,0C,0D,0F,10,1C,20,
ERROR: subfunction not supported
ENGINE_LOAD: 0%
ENGINE_COOLANT_TEMP: 25°C
ERROR: subfunction not supported
INTAKE_MANIFOLD_ABSOLUTE_PRESSURE: 100kPa
ENGINE_RPM: 0rpm
VEHICLE_SPEED: 0km/h
ERROR: subfunction not supported
INTAKE_AIR_SENSOR: 30°C
MAF_SENSOR: 0g/s
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_21_40_SUPPORTED: 21,23,40,
DISTANCE_SINCE_ERROR_INDICATED: 2660km
FUEL_RAIL_PRESSURE_CT_VACUUM: 0kPa
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_41_60_SUPPORTED: 60,
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
PIDS_61_80_SUPPORTED:
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported
ERROR: subfunction not supported

The program also comes with auto auto incremented version numbers, this is made through Ant Build tasks. The program version can be checked in a About form.
Furthermore I found more interesting reads:

http://www.canbushack.com/blog/index.php?title=scanning-for-diagnostic-data&more=1&c=1&tb=1&pb=1

https://pcmhacking.net/forums/viewtopic.php?f=3&t=3224&start=350

after hours coding

post-IT-study chronicles