Warning: file_get_contents(): php_network_getaddresses: getaddrinfo failed: System error in /srv/http/nimdraug.com/wp-content/themes/nimdraug-2018/class/theme.php on line 24

Warning: file_get_contents(https://nimdraug.com/wp-content/themes/nimdraug-2018/.version): failed to open stream: php_network_getaddresses: getaddrinfo failed: System error in /srv/http/nimdraug.com/wp-content/themes/nimdraug-2018/class/theme.php on line 24
Nimdraug.com https://nimdraug.com Melbourne based Web-developer Tue, 07 Mar 2023 02:10:31 +0000 en-AU hourly 1 https://wordpress.org/?v=6.1.5 Ivette – Build Log 2 – Case Build https://nimdraug.com/hacker/ivette-build-log-2-case-build/ Fri, 18 May 2018 02:23:13 +0000 http://nimdraug.com/?p=142 In the interest of actually getting this done, I will try and keep this as brief as I can. I might, however, elaborate at a later stage.

Day 0

After much waiting the day had finally come, when the parcel collection card for my screen showed up in my mailbox, meaning I could finally start the build. I picked it up from the post office straight away, and un-boxed it on my lunch break at work.

I also tried out some ideas for possible internal component layouts, using the provided cables. In doing so, I found that I had to have the HID USB cable sticking out of the case in order to have the rest of the RPi’s ports be accessible from the outside. While this was inconvenient, there was not much I could do about this without doing some heavy modifications to the ports, which I was not ready to do. So I would have to live with that slight issue for the time being.

Day 1

The actual case build started the following day. I selected a few good thick pieces of cardboard, with as few dents and damage as possible, from my stash of old boxes. I then traced out the edge of the screen with a felt tip pen onto one of them, and cut that out as a template. That template was in turn used to trace and then cut out 6 case layers (which I will refer to as Layers 0 through 5).

With the case layers ready, I decided to test the screen to make sure it actually worked. But as described in the previous post, I could not get it working at first. But luckily after first sort of getting it to work on my house-mate’s Windows Laptop, I finally got it to work completely on the RPi. Huzzah!

Relieved the screen was working, I continued with the case. I cut out holes in Layer 0 to fit the back of the screen, as well as some holes to possibly fit camera, light sensor, and microphone in the future. Layer 1 was also marked up fit the controller board.

I then had to pack up shop, to get ready for a weekend full of events, followed in the next week by my friend’s wedding up in Brisbane. I did, however, made sure to pack everything I needed for the case in my luggage (except for any sharp objects of course) so I could continue building during any downtime while I was up there.

Day 2

I arrived in Brisbane for my friends’ wedding, and after some initial wedding commitments, I went and bought the tools I was unable to bring with me on the plane, and then set up shop in my friends’ garage/workshop. There I worked on Layers 0 to 2, cutting out holes to fit the RPi, which I had now decided to put on top of the controller board, as well as grooves and holes in Layers 1 and 2 to fit the inner cabling.

The next few days where full of wedding celebrations and other fun events, so I did not work much on the case before heading back home.

Day 3 + 4

Once back home again, I continued by working on Layers 3 and 4. Cutting out holes to fit the Battery and the RPi. I tested the cut layers with the RPi and battery inside which fit pretty nicely. I then tested with the cabling and found that the fit was not as good, so I cut out some more. Then with the RPi and the Battery connected to each other inside the case, the RPi turned on with all the pretty lights shining out from the holes in the back of the case.

Day 5

A few of days later I cut out the final layer, Layer 5, to fit the back part of the battery. And now, with all the layers cut, I needed a way to hold them all together. I was going to glue most of them together, but since I needed access to the inside, gluing them all together would not be a good option.

So one night, a couple of nights previous, when I was pondering the issue, I was going through what I had available in the house, which could be used to hold the layers in place. I did not have any suitable nuts and bolts so I tried to think of what was more readily available. I then thought, in keeping with the case’s somewhat recycled theme, maybe some plastic bottle caps could do the trick. But a quick check of the recycling bin proved fruitless. But then it dawned on me, something we did have was used toothpaste tubes (I lived in a sharehouse, so we often had multiples of things). After a bit of shameless bin-diving, I managed to find three tubes, which I deemed would be enough.

I cut the top parts of the tubes off and cleaned out any left-over toothpaste. Then using the base of one of the cut out lids as a template, I marked up and cut out a hole for it to sit in.

Day 6 + 7

I worked out that creating and using a template was the best way to ensure that the holes would line up across the layers. I made a smaller test template first, for just one of the caps, and then a couple of days later, a full-sized one which covered the whole case. I first traced the toothpaste caps onto the template and then used a compass and ruler to make the circles more precise.

Day 8

I had a bit more time on this day so I decided to work on a script to control the back lighting of the screen. This was done as a sort of proof of concept for developing on the tablet. I was unable to get Sublime running on it (since it’s an ARM system), so I had to resort to using nano (I know, I know, how terrible. I don’t know enough VIM to use it comfortably, okay?). Progress was a bit slower than I was used to, but I managed none the less.

I used the documentation provided by the screen’s manufacturer along with the cython-hidapi library to work out how to communicate with the screen correctly. The script ended up working pretty well, except running it would disable the screen’s touch capability for some reason, which was quite an obvious downside. The lack of good documentation and the manufacturers reluctance to answer my emails meant that this issue has not yet been fixed. But my assumption is that this happened because the documented commands where meant for the latest version of the firmware, and since I have not yet updated the firmware, the commands won’t work as expected. I didn’t have the time to debug the issue any further so I decided to leave it until a later date, and continue with the rest of the build.

The script can be found on my github page.

I continued marking up and cutting out holes for the toothpaste-case-screws using the template I had made.

Day 9

I finished cutting out the holes for the toothpaste-screws through all the layers, meaning that the layers where finally ready to be glued together. I started by gluing in the Audio cable with gun glue, and continued gluing the layers using PVA, ending up with two halves. I put the glued case halves under a bunch of heavy books (mostly the whole Song of Ice and Fire series) to serve as a sort of vice, to make sure all the layers would bond properly.

Day 10

The following day I got the two glued halves out from under their temporary book-vice and found that all the layers had bonded nicely. I was a little bit rushed to finish the build that evening, because I was determined to show the tablet at work the next day.

The final step involved the only bit of soldering I had to do for the whole build, which was to create the power cable for the screen. This cable would be created from the one provided with the screen as well as an old spare USB cable I had lying around. I cut the two cables and stripped back the outer sheathing to expose the wiring within. Through the magic of looking things up on the internet, I worked out which of the coloured wires needed to be connected together for the cable to work. Turned out that red was to be connected to red, and black to black (I did say that my electronics knowledge was a bit rusty). I stripped the insulation from the wires and twisted them together and tested the cable, which to my delight worked. I then popped some shrink tubing onto the cable, soldered the wires together, wrapped some electrical tape around the soldered wires, and finally heated the tubing to shrink around the join. A final test of the cable proved that everything had been done correctly (yay!).

With the screen’s power cable finished, the tablet was now ready for its final test. I hooked up all the components on the screen half and then attached the back half. When I turned the device around I saw that it was booting correctly and I was happy to know that it was finally ready for demonstration and general usage.

Day 11

Having completed everything the night before, I now brought the finished prototype tablet with me to work, to demonstrate it for my Show and Tell during the Monday morning meeting. The demonstration was met with impressed bemusement.

And with that, the case build was complete.

Hope you have enjoyed reading this article. It took me way too long to write but I am glad it’s finally done. The next iteration of the tablet (Ivette 2) is well under way, and there will hopefully be some updates about that one sometime soon.

]]>
Taters gonna tate https://nimdraug.com/programmer/taters-gonna-tate/ Sat, 22 Apr 2017 16:56:43 +0000 http://nimdraug.com/?p=532 After a long day of project organising, coding and general cleanup, taters is finally pushed out to github and is now officially available to the general public.

So before I go into a bit more detail about the project, Check it out Now!

Taters is the result of years working as a web-developer where common tedious tasks quickly got automated with scripts to make life easier and allow me to focus on actually making websites. Tasks like building source files into assets and then getting those assets onto the clients servers where the most common ones to get automated with scripts. These scripts then grew in complexity and eventually became very difficult to extend and maintain. Other similar systems like grunt and gulp inspired me to rewrite my scripts from the ground up in a more modular fashion, dealing with many of the issues I had encountered along the way, improving on shortcomings I perceived with the other systems, and incorporating many of the ideas and concepts I had wanted to try out, with the final goal being to have something that could be useful for more than just web-development work.

I have been using taters in my work for a while now, and have always wanted to share it with the public, but it needed a bit more TLC before I felt it was ready. And with changes at work meaning that more people, other than just myself, where going to use it, there was a bit more incentive for me to actually get it to a better state. Initially, it was simply called deploy, since that was essentially it’s primary function. But I felt that name was a bit too generic and also somewhat limiting in it’s scope, so I eventually settled on taters. Now, exactly why I chose taters is not entirely certain, but it most likely has something to do with my general fondness of the tuber as well as my general Hobbit-ness.

Getting the project onto github is of course only the start, as there is still much work to be done before it’s actual version 0.1 release, and even more work still before the illusive version 1.0. The next big thing that needs doing is documentation, which is a difficult and big task but also a very necessary one.

So anyway. I am quite excited!

]]>
qr-send: a simple image-based transmission method https://nimdraug.com/programmer/qr-send-a-simple-image-based-transmission-method/ Thu, 09 Feb 2017 12:53:19 +0000 http://nimdraug.com/?p=516 Long time no post. So to make it easy for myself to get things started for this new year, I will post about something small and simple. Namely, qr-send.

qr-send is a solution to the problem of “How do I get short bits of text from my computer to my phone?”

Sometimes there might be a URL or a short bit of text you need to get onto your phone for whatever reason. Maybe you find an article you want to read later on your way home from work, maybe you have a bit of text in a document that you want to text over to a friend, or if you are a web-developer like me, you might want to open a website in your device’s web-browser to make sure everything works on the smaller screen.

Sure, you could just type it out. But unless the text is really short then that might not be that easy. You might have a long and complicated URL or other bit of text which contains a bunch of random looking characters, like a hex-encoded hash. Then it would be both tedious to type it out by hand, and there would be a high risk of making mistakes. So manual typing here is not an option.

Now, depending on your device, you might have a whole range of other options available. You could send it via Wifi, but what protocol would you use, and what about security? You could use Bluetooth, but you would need a Bluetooth dongle in your computer. Also many of these options requires a fair bit of configuration to get working satisfactory. You could also download some App™ to both your computer and your device which sends the text via The Cloud™ somehow, but personally I try and avoid those sorts of solutions as much as I can.

qr-send, however, is a very simple solution to this problem (At least compared to some of my examples above). All it does, is it takes the text you wish to send as it’s input, encodes that text into a QR Code image, and then displays that image on your screen. And then all you have to do is open up your QR Code scanner of choice on your device and scan the code, and the text will appear on your phone ready to be copied opened with your browser or copied to wherever it’s needed. Simple as that.

setup qr-send

So to get this all set up, you first need somewhere where you can enter in the text you want to send into. For this I use zenity. Zenity is a command which makes it easy to add GUI dialogs to shell-scripts which I have used quite a few times due to it’s simplicity. If you run a UNIX-based system then you should have no issues installing it with your system’s package manager.

So to get a dialog that accepts basic text input and then outputs it to stdout you just run the following:

[code lang=”sh”] zenity –entry
[/code]

You can customise the dialog further by adding a title and description etc, but for our purposes a simple input will suffice.

Then you need to generate the QR Code image. I do this with qrencode, which is a QR Code generation command with whole bunch of useful options. It should also be readily available in most package managers.

To get it to encode text from stdin into a png file, you run the following:

[code lang=”sh”] qrencode -o qr-code.png[/code]

Combine it with the zenity command from before, and you now have QR Code images being generated from input provided by the GUI dialog:

[code lang=”sh”] zenity –entry | qrencode -o qr-code.png
[/code]

The QR Code image is still being stored as a file, tho, which you will then have to open separately to be able to scan. And we want to have the QR Code displayed on the screen straight away. For this purpose I use feh, which is a very lightweight but versatile image viewer, very much made with the UNIX-philosophy in mind, where it displays images and not much more. It too is easy enough to install on most UNIX-based systems.

To get feh to display the image generated in the previous example, you just run the following:

[code lang=”sh”] feh qr-code.png
[/code]

But feh can just as easily read the image from stdin by providing the special <code>-</code> filename. So to combine it all together, you just need to get qrencode to output the QR Code image to stdout by also using the special <code>-</code> filename, and then pipe the resulting data to feh, like so:

[code lang=”sh”] zenity –entry | qrencode -o – | feh –
[/code]

And there you have it. Now you can add that one-liner to a shell script, and then have it run by a launcher in your desktop environment of choice, or even setup a keyboard shortcut for it for extra quick access.

TL;DR or “here’s one I prepared earlier”

Since I have already implemented this script for myself, I have also made it available on my github. The repository also comes with the added bonus of a little script which generates a nice icon for use with any launchers for the main script.

Just pull from the repository using git:

[code lang=”sh”] git pull https://github.com/Nimdraug/qr-send
[/code]

or visit the repository directly at https://github.com/Nimdraug/qr-send and download it from there.

]]>
Keep bootstrap from taking up space and time in projects https://nimdraug.com/web-developer/keep-bootstrap-from-taking-up-space-and-time-in-projects/ Tue, 20 Sep 2016 11:03:23 +0000 http://nimdraug.com/?p=93 If you are anything like me, then you probably have a bunch of web project’s git repositories in a folder on your computer, each with their own copy of bootstrap on them setup as a git submodule. That is all good and well, but you might not know that all of those bootstrap copies (as of writing) take up 104.8 MiB each! Which if you manage lots of sites like I do then it easily adds up to a few GiB. This article will go through a method of limiting the space that these copies take up as well as save you some time when you setup new projects.

The depth method and why it’s bad

Before we go into the details of this method I would like to outline another method I’ve seen talked about around the net. This is the depth method.

This method uses the –depth attribute when checking out a submodule (using clone or update) which makes git fetche only the number of revisions defined by the –depth attribute, creating a shallow clone of the repository.

[code lang=”sh”] git submodule add https://github.com/twbs/bootstrap.git bootstrap
git submodule init
git submodule update –depth 3 bootstrap
[/code]

The above example only fetches the 3 latest revisions from bootstrap.

This might seem like a great way to fix the issue when you first start your project, but if where to apply the same solution to an older project it will most likely all fall apart. This is because if your project uses an older version of bootstrap, then its submodule will be referencing a revision which is older than the latest 3 revisions (or however many you chose to use) and updating the submodule will result in a nasty error:

[code lang=”sh”] $ git submodule update –depth 3 bootstrap
Cloning into ‘/home/x/repo/bootstrap’…
error: no such remote ref 0b9c4a4007c44201dce9a6cc1a38407005c26c86
Fetched in submodule path ‘bootstrap’, but it did not contain 0b9c4a4007c44201dce9a6cc1a38407005c26c86. Direct fetching of that commit failed.
[/code]

This means that the depth method will only work if you intend on always keeping your submodules on the bleeding-edge, which in my case was not maintainable.

Enter the reference method

Since the depth method did not work out for me, I had to find an alternative. And what I found was that you can make a submodule use a reference repository for it’s revisions. What this means is that you only have the submodule’s referenced revision checked out in your main repository. All other revisions are stored externally, which makes it possible for multiple repositories to use the same reference repository for their submodules, thus saving a fair bit of space. In my case the bootstrap submodule with the reference took up 11.6 MiB instead of 104.8 MiB, which is almost 90% smaller.

Another benefit of using a reference repository is that you don’t have to download the whole repository each time you start a new project, which would usually not be much of an issue due to my work’s fancy internet connection, but sometimes connection speeds do drop and living in Australia makes this a far too common issue.

To setup bootstrap as a referenced submodule you first need to clone bootstrap into a common location outside of your project.

[code lang=”sh”] mkdir reference-repos
cd reference-repos
git clone https://github.com/twbs/bootstrap.git bootstrap
[/code]

Then if you are setting up the reference in a new project you add bootstrap as a submodule as usual

[code lang=”sh”] git submodule add https://github.com/twbs/bootstrap.git bootstrap
git submodule init
[/code]

Now here comes the magic. Update the bootstrap module on it’s own with the –reference option set to the reference repositorie’s path

[code lang=”sh”] git submodule update –reference ../reference-repos/bootstrap bootstrap
[/code]

And that’s it. The submodule is now using the reference repository as the source for it’s revisions.

Now you can update any other submodules as normal.

[code lang=”sh”] git submodule update
[/code]

Changing existing submodules to use reference method

It is more likely that you already have a bunch of repositories with bootstrap setup as a submodule the normal way. So you need to know how convert them over to use the reference method.

First you need to deinit the bootstrap submodule, which clears the bootstrap directory

[code lang=”sh”] git submodule deinit bootstrap/
[/code]

Then you need to remove any cached repository data from the submodule out of your current repository. Each submodule you have in your repository has it’s revision history and other repository data stored in the .git/modules directory. So you need to remove the bootstrap one from there, otherwise the submodule update command will just use that data again instead of there reference.

[code lang=”sh”] rm -rf .git/modules/bootstrap/
[/code]

And now you can just init and update the submodules as described in the previous section, remembering to update the bootstrap one separately with the –reference option.

[code lang=”sh”] git submodule init
git submodule update –reference ../reference-repos/bootstrap/ bootstrap/
git submodule update
[/code]

And there you have it. Your existing bootstrap submodule is now referenced as well.

Downsides with the method

When researching this, I happened upon an article which referred to this method as harmful. The reason being that the reference is made using an absolute path in a file in the submodule’s configuration directory (.git/modules). This means that if you ever do a backup of your repositories to a place where the reference repository is not present or if you ever remove the reference repository, then you will not be able to use the submodule.

To fix this, you would need to deinit the submodule and then setup the reference again or just set the submodule up like normal.

For me this is not a huge issue, because I keep all my repositories in one directory including the reference repositories and I always back up that entire directory. Yes, the place I back it up to will most likely not have the same directory structure, but if I ever need to restore stuff then it should all work. Also I am fully aware that my bootstrap submodules are setup using a reference will never remove the reference repository, at least not on purpose anyway.

]]>
Ivette – Build Log 1 – Hardware https://nimdraug.com/hacker/ivette-build-log-1-hardware/ Fri, 16 Sep 2016 11:50:37 +0000 http://nimdraug.com/?p=112 After much anxious waiting I finally received the last piece of hardware for Ivette, my DIY tablet build, and that part was the LCD Touchscreen. So, with all the parts on hand, I excitedly started building the case that weekend. I continued building whenever I had any spare time and only just finished it a few of weeks ago. And now that I have tried it out for a bit, it is now due time to document the build process. But before I that though, I would first like to go through and document the hardware in more detail and outline the general hardware design of Ivette version 1.

Hardware Overview

The number of parts in this build is rather low, mainly because I wanted to have a proof of concept device up and running as soon as possible, to show off and play around with. The main parts are as follows:

  • Raspberry Pi 2
  • 100,000 mAh (?) Mobile Battery
  • Chalkboard Electronics – 10″ HDMI LCD with Capacitive Multi-Touch

Other parts include the cabling that came with the screen and battery and also a bunch or cardboard for the case, which I will cover in upcoming build logs. Also I have an assortment of dongles that I can plug in to the Raspberry Pi to give it further capabilities like WiFi etc.

I already covered some of the hardware in my previous build log, but now I would like to go into more detail on their specs and also why I chose to use them.

Raspberry PI 2

The Raspberry Pi 2

The Raspberry Pi 2

The Raspberry Pi line of SoC boards are great little computers with a million and one uses. And I have thoroughly enjoyed using them in many a fun project for a couple of years now. They are great because they are basically the PC of the embedded world. No locked down hardware (well mostly) that requires jail breaking (with potential bricking) to get the system you want. Just pop your favourite version of Linux on an SD card (Or other OS, but why you would do that tho, I do not know), plug it in, and start playing. And its super easy to extend it with additional hardware with a huge range of options to choose from, which is very different from pretty much all tablets out there.

The reason I went for the RPi2 was primarily because I had it on hand, and also because it has some pretty good specs, at least compared to the RPi1 and RPi0. I didn’t want to be too limited in what I could do with it, so better performance is always a good thing. But I also did not go for the newer and better RPi3, cause it is just too power hungry and the fact that I would possibly need to add a fan or other cooling to not have it overheat was a bit of a turn-off. That said, I might upgrade to it in the future, because built in WiFi and Bluetooth are some quite nice features.

Other features I like with the RPis is that they have built-in Ethernet ports, allowing me to gain faster and more reliable network connection when that is available, something most tablets of today have dropped in favour of thinner devices. Also the GPIO connector is really nice for when I eventually want to do some more in-depth hardware hacking.

One downside to the RPi2 is that it is fairly bulky due to it’s Ethernet and USB ports which increases the overall thickness of the device. This can be mitigated by de-soldering them off the board and running them to the edge of the case with wires, something I will most likely do in later versions. Also, the standard Audio jack on the board is not very good at all. It suffer from electrical interference from the board during operation where you get a staticy crackling noise when the CPU load goes up. This can be overcome, however, but just telling the RPi to direct the audio to the HDMI port instead.

For more info on the boards please see:

And here, have some specs (from Wikipedia):

Target price US$35
Architecture ARMv7 (32-bit)
SoC Broadcom BCM2836
CPU 900 MHz 32-bit quad-core ARM Cortex-A7
GPU Broadcom VideoCore IV @ 250 MHz
OpenGL ES 2.0 (24 GFLOPS)
MPEG-2 and VC-1 (with license), 1080p30 H.264/MPEG-4 AVC high-profile decoder and encoder
Memory (SDRAM) 1 GB (shared with GPU)
USB 2.0 ports 4 (via the on-board 5-port USB hub)
Video outputs HDMI (rev 1.3), composite video (3.5 mm TRRS jack)
Audio inputs Via I²S
Audio outputs Analog via 3.5 mm phone jack; digital via HDMI and I²S
On-board storage MicroSDHC slot
On-board network 10/100 Mbit/s Ethernet (8P8C) USB adapter on the USB hub
Low-level peripherals 17× GPIO plus the same specific functions, and HAT ID bus
Power ratings 800 mA (4.0 W)
Power source 5 V via MicroUSB or GPIO header
Size 85.60 mm × 56.5 mm, not including protruding connectors
Weight 45 g

Mobile Battery

Battery Connections and Features

Battery’s Connections and Features

I bought this mobile battery quite cheaply off eBay. It was advertised as “100000mAh For Mobile Phone Solar Power Bank 2 USB Portable Backup Battery Charger”, and with a price-tag of around $20, it sounded like a pretty good deal.

Now the main reason I chose this one was due to it’s capacity, however, since I bought it, a few friends have pointed out that it could not possibly have 100,000 mAh of charge in it. Primarily because of its rather small size and weight. But it was only a couple of dollars dearer than those with less capacity so I went for it. Another thing that drew me to it was the fact that it had a solar panel, which I thought could come in handy in case I needed to charge it somewhere where access to mains power would be limited. And since I enjoy sailing and am going travelling next year, who knows when this might come in handy. Of course, I do not imagine that the solar panel would charge the thing very quickly, but this remains to be tested.

Other features include a high intensity LED light which can be activated with the power button, and 4 LEDs which indicate the available charge. The high intensity LED won’t be very useful for this project but it is also not a downside. The power indicators however, are quite handy. Especially if I want a super easy way to hook into the charging board, to for instance make the current available charge available to software. In theory, all I’d need to do is de-solder the LEDs and then connect the solder points to something, most likely the GPIO on the RPi. My proficiency in electronics is not great and have yet to explore what is possible with the GPIO bus, but I remain ever hopeful.

The battery has 2 outputs, one 2A, and one 1A, which was another selling point for me. This meant I could use the 2A one for the RPi, which is the recommended input current, and then use the 1A for the screen, which is slightly lower than the screen’s recommended input current, but I figured I could just turn down the back-lighting to keep it from drawing too much.

Once I actually got the Battery, I put it through a bunch of tests and found it to be very reliable and that it does hold a fair bit of charge. Most likely not 100,000 mAh, but still a fair bit. As I said in my previous build log, I was able to run my RPi2 with WiFi and a wireless keyboard as well as an external hard-drive for a couple hours and still had enough charge left to charge my phone a couple of times. And since then I managed to run the system for quite a few hours while doing a bunch of work, and the charge only going down to about half. I now keep the battery with me at all times to ensure my phone never runs out of battery, and my partner likes it so much when we are out and about, that I am going to have to get her one now as well.

It does, however, have one major downside. It is not possible to have it charge something while it is getting charged itself. This includes it getting charged with the solar panel. So if I am charging my phone while outside I need to ensure its tucked away in a big pocket or in a bag or else sunlight will set off the solar panel and the phone will stop charging. This also means that I cannot have the solar panel exposed when the battery is connected to Ivette or a stray sunbeam will cause the system to power off, which for a RPi could mean a corrupted SD card (oh the horror).

But despite this I thoroughly like this battery. For later versions of this build I will most likely be taking it apart to see how it works and see if I can mitigate the issue somehow as well as see if I can give it an even smaller footprint.

And maybe I will finally find out how much it’s actual charge is. That, or break it forever. But hey, it was only $20.

Here’s some specs from the eBay description:

Capacity 100000mAh
Input Voltage DC 5V / 1A Max
Output Voltage Output 1: DC 5V / 2.1A; Output 2: DC 5V / 1.0A
Charging time 7-11h
Size 143 X 75 X 9mm

10″ HDMI LCD Touch Screen

LCD Touchscreen Front

LCD Touchscreen Front

LCD Touchscreen Back showing Control Board

One of the most important parts, if not the most important part, the one that turns what is essentially just a portable Raspberry Pi into an actual tablet, is the LCD Touchscreen. And this, of course, was the part that cost the most and took the longest to deliver.

It finally arrived on a Friday before a weekend full of parties and celebrations, which in turn was before a big flight up to Queensland for a friend’s wedding. I had really hoped to receive it earlier so that I could have the case build finished before I headed up. But after weeks of intensive work, this proved to be a highly over-optimistic goal.

I ordered the screen of a company in Malaysia called Chalkboard Electronics. And that explains why it took longer than expected to ship here, what with all the customs and such. I got linked to the screen by one of my inspirations for this project, the PiPad by Michael K Castor. However, the PiPad used another screen model which is no longer available, but the differences are not that many. Mainly a different native resolution and different layout of holes for things like cameras and the ambient light sensor. Also the from photos it looks like the control board is quite different so I’m guessing that was an earlier version as well.

The controller board that comes with the screen takes the touch screen part and makes it available as an HID touch device through its mini USB port, which is single-touch by default, but can be turned into multi-touch by upgrading the boards firmware. The controller also has a mini-HDMI input which makes it very easy to connect to the RPi which has a very convenient HDMI out port.

Another benefit of the controller board is that it can take an audio signal sent over the HDMI cable and split it out to it’s 2.5mm jack, which means that there is no need to use the dodgy audio output from the RPi. No more crackling audio.

One downside with it is that it takes power from a rather narrow coaxial power connector. So just to be certain that I had the correct connector, I opted to also get the official power adaptor with the screen, only issue was that they only had EU/UK or US plugs and no Australian ones. But I had an old travel adaptor collecting dust somewhere, so at least I would be able to power the screen when I got it. Also I figured that I would be able to Frankenstein the connector end with an old USB cable to make it possible to power the screen from the battery.

The board does support powering the screen from the mini USB port, but that requires you to shift a surface mounted resistor, which is something I am definitely not capable of doing. And also that port was going to be connected to the RPi, which meant it would be drawing power from it as well, and sharing the RPi’s 2A instead of having it’s own 1A would not work at all.

With the screen I had also ordered a few cables, as well as the aforementioned power adaptor. Those where an ambient light sensor, an 2.5mm to 3.5mm audio adapter, and the required HDMI and USB cables. The ambient sensor allows the screen to adapt the back-lighting to the current surrounding lighting conditions, but since I was going to run the screen of less current than recommended, I ended up not using the sensor, for fear of it trying to draw too much. The audio adaptor came in very handy to lead the audio jack to the edge of the case making it easy to connect headphones to the tablet.

All in all this has been a great purchase. It did set me back over $200 (including cables and postage), but it was definitely worth it in the end.

Heres are the screen’s specifications taken from the official website:

Display 10” full-color a-Si TFT with IPS technology
Integrated touch-panel capacitive multi-touch with up to 10 fingers
Native resolution 1366×768 pixels
Aspect ratio 16:9
Display colors 16 millions (8-bits per color)
Panel dimensions 269mm (H) x 172mm (V)
Weight 245 grams
Input voltage 5V DC
Low power consumption 2.5W (typ)
High brightness 450 cd/m2 (nits)
Contrast ratio 800:1
Viewing angle 89 deg (all directions)

More information and options to buy your own can be found on the manufacturers website:

Hardware Layout

Ivette-1-block-diagram

Block diagram of Hardware Layout

The hardware layout of the device (as seen in the right image) was chosen to be as quick and easy as possible to assemble using as much of the cabling I bought with the screen as I could. I also wanted to do a minimal amount of soldering or other electronics work since I did not trust my skill. Luckily all the cables I got with the screen where all that was required, except for one cable for powering the RPi which came with the battery. And I only had to modify and solder one cable, what I now refer to as the Frankencable, which supplies 1A of current to the Screen. And leaving the frankencabling till last meant I could build everything else and still be able to use the device by just having the screen’s power adaptor plugged into the wall.

One great benefit of this design using standard cables like USB and HDMI, is that any part can be easily replaced (except maybe the screen). If I want a different battery. Too easy, just replace it. Upgrade to a RPi3? No worries (just need to provide a bit more power, probably). Cable broken? Buy a new one for a couple of dollaridoos. Bluetooth support? Pop another Dongle in, she’ll be right.

Testing the Design

The Hardware layout design was worked out and everything looked rather nice and simple and should not cause too many issues. At least, that was the theory. I had yet to actually test the design. So once I had all the parts I decided to do just that. But the first time I hooked everything up I had a moment of terror. I connected everything with the screen pointing downward (the control board is on the back), I turned the power on, a little green LED on the Control Board turned on, I excitedly turned the screen around but on the other side there was nothing. No image or anything. I checked to see if the RPi was working by (blindly) logging in and then telling it to power off, which it did, so that wasn’t it.

I was really worried that the screen was broken somehow, but not giving up, I asked my housemate if I could borrow his windows laptop. I had a hunch that maybe I wasn’t getting an image because the back-lighting was turned all the way down, the screen seemed to be working otherwise. I needed a windows computer because the manufacturer has a program available on their site to control the back-lighting and the simplest one to get working, I thought, would be the pre-compiled windows version. I installed the program and hooked the screen up. Windows recognised the HDMI screen, as well as the HID device, and the touch sensor even worked. So clearly that part of the screen was working. I started the program, and suddenly I got an image on the screen, hurray! But as soon as it appeared it was gone. On it came again, and then gone again. The screen was blinking, and so was the control program. Something was not right.

I tried getting it to work for a while but could not get it to stop blinking. So I thought, maybe its just a Windows thing, or the program had not been tested for Windows 10. So I figured I’d give it another go on the RPi and maybe compile the controller program remotely, or something. So I hooked it up with the screen facing down again and turned the power on. Suddenly the backlight came on (it had not done that last time) and lit up the whole back of the screen, and most importantly, it stayed on. When I turned the screen over, I was greeted with the lovely Linux boot sequence and finally a login prompt. The screen worked! And better yet, the design worked!

Well, mostly anyway. The screen was still running of mains power and I still was not sure the screen could be run off 1A from the battery. And I would not know that until the end of the build when the frankencable was completed. I could have constructed it then to make sure absolutely everything worked, but I had a weekend full of events and a flight to catch the following Monday, so time was limited. And I really wanted to get started on that case.

And next post will cover that case build. It took a fair bit longer than I expected and there are a lot of photos so I will most likely spread it out over a few posts. And after that I will document some of the issues I had with this design and my ideas for fixes and improvements going forward to Ivette version 2.

]]>
LCD Control script for Chalkboard Electronic Devices https://nimdraug.com/programmer/lcd-control-script-for-chalkboard-electronic-devices/ Tue, 23 Aug 2016 02:41:24 +0000 http://nimdraug.com/?p=107 Last weekend while working on Ivette, I needed to be able to control the backlighting on the screen so I spent Saturday afternoon to very late in the night with a bottle of merlot coding away on a script to enable me to do this from the shell. I implemented it with the help of the somewhat inaccurate but still excellent official documentation on the subject.

I released the results of this effort onto my github account. There are still a few bugs and some minor features missing but the script works really well on my device.

To checkout this script just go to it’s github page at https://github.com/Nimdraug/lcdcontrol

Any help with testing the script on other devices or general bug testing would be highly appreciated.

]]>
Ivette – Build Log 0 https://nimdraug.com/hacker/ivette-build-log-0/ Sun, 24 Jul 2016 14:04:05 +0000 http://nimdraug.com/?p=66 This series of articles will cover some of the details and build of a Raspberry Pi based Tablet Computer I call Ivette. The first instalment will serve as an introduction to the project and go through how and why I started it and also detail the first iterations of the device.

Introduction

It pretty much started with my old Acer Aspire One becoming unusable as it hit its end of life date. It’s battery was unable to hold the smallest of charges, and it’s charger barely held on to it’s connector and a quick jerk of the cable would mean it would be completely without power. And being a netbook that is somewhat of a requirement. And since I mostly used it to code while on public transport to and from work, I needed to find myself a suitable replacement.

But this, however, proved to be quite difficult. Mainly because I am quite picky with what I buy when it comes to computers (among other things) so the resulting device had to tick some rather strict boxes. First and foremost, it had to be able to run Linux, Arch Linux to be precise, since that is my distro of choice. Secondly I also wanted it to have touch screen since TUIs is something I would really like to experiment with. It also had to be small enough to carry around with me to enable me to code wherever I may be. This also required it to have or be able to connect with some form of keyboard, cause coding on a touch screen would suck.

All of these requirements limited me a fair bit. I found a few laptop/tablet hybrid options that looked promising, but they where ARM based Android or Windows devices with fairly proprietary hardware setups which would make installing Arch Linux a hard task with a possibility of not being able to get everything to work due to lack of drivers etc. So committing to pay for a device I might not be able to use 100% was not very encouraging. This is also why I have never bought myself a tablet and even though I considered getting one a few times during my search, my stubbornness prevailed. x86 based devices where also considered, but for whatever reason (finances most likely) that did not pan out either.

One device that I really do like to work with, though, is the Raspberry Pi. I have had a couple of those little things for a while now and have used them for various projects. The fact that there is a version of Arch Linux for it, a large community of users for support and an extensive catalogue of compatible hardware makes it a very nice and easy platform to use for anything.

So having seen Raspberry Pi based tablets in the past I thought that might be the answer I was looking for. Some quick research brought up a very nice tutorial from Ada Fruit detailing a DIY tabled which used parts from Ada Fruit as well as the official 7″ touch screen from the Raspberry Pi Foundation. So I set out to try and replicate this device as much as I could. But this proved to be more difficult than I had anticipated. Either the parts I needed where constantly out of stock or (in the case of the batteries) where too expensive to ship over to Australia, most likely because of customs etc.

Michael K Castor's PiPad

Michael K Castor’s PiPad

Frustrated and half fearing some form of curse, I restarted my search. But this time I stumbled across an old article about a similar project by Michael K Castor. This PiPad, as he called it, is surprisingly simple in its construction. In its code its pretty much just a Raspberry Pi, a mobile battery and a HDMI touch screen with a few extra bits added. The battery would be super easy to find, just a quick search on ebay and you will find 100s of options with varying capacity for very little money. So the only real kicker was the screen. Unlike my previous option, this one was 10″ as opposed to 7″ which felt much more appropriate for a usable tablet. I was also in luck because the company that he had sourced his screen from, Chalkboard Electronics, had an upgraded version of the same screen available for purchase.

So I had finally found my replacement every-day-out-and-about computer.

[clearfix]

Ivette 0

20160623_001

Installing Software and testing web browser

Having finally found what my replacement device was going to be I was eager to get started. But I had to wait until I had enough funds to get the required parts, and in the mean time I needed to spend my creative motivation somewhere. So I started working with what I had available, namely my Raspberry Pi 2 and other parts I had lying around, to get the software part of the project going. Things like installing the base Archlinux System and any packages that I thought where needed to make it usable when out and about.

This system I called Ivette 0, a proto-ivette if you will.

Now, before I continue, I just want to mention why I call the system Ivette. This is simply because it is named after my main computer Ivy (after Poison Ivy, my computer naming scheme is Super Villains or rather Super Villainesses), but since it’s a tablet i used the french female diminutive suffix.

I got to test Ivette 0 out in the wild when I travelled with my partner to a wedding a few hours out of the city. It did not go too well since wireless coverage in the motel was quite poor and I had missed some important packages to make the system do anything usefull. The Raspberry Pi 2 performed rather well as a media system, though, thanks to Kodi.

20160626_003-smaller

Ivette 0’s Hardware

[clearfix]

 

Ivette 1

100000 mAh battery

100000 mAh battery

The first piece of hardware I bought for the device was the battery because it was the cheapest. After much deliberating I ended up going for a 100000 mAh battery with a built in solar panel which ended up costing me little over $20 AUD which is just a bargain for what you are getting. The battery has 2 USB ports, one 1A port which will be used to power the screen (should hopefully be enough) and 2A which will power the Pi2 and it’s attachments (WiFi etc).

Then later when I had the funds I ordered the screen along with a bunch of extra cables and stuff which will come in handy for setting up external ports and wiring everything up. One nice feature of the screens control board is that it breaks out HDMI audio to an audio jack so I don’t have to use the RPi one which has some noise issues. This ended up setting me back about $250 AUD.

The case will be constructed out of cardboard, which if you know me is not a great big surprise. It is my go to material for prototyping because it’s cheap and easy to source and I don’t have to have access to CNC machinery etc.

I received my battery just the other day and have been testing it a fair bit and I love it. I was able to run my RPi2 along with an external HDD for a few hours as well as recharge my mobile a few times before I had to recharge the battery pack itself.

It is my earnest hope to have received the screen early next week so I can get everything assembled and ready before I head up to Brisbane for another wedding and give the system another test in the wild. This time I have had a lot more time to work on the software side of things and I think it’s ready for another trial by fire.

So if all goes well, then I will detail all of that in the next article.

]]>
Hello World! https://nimdraug.com/programmer/hello-world/ Thu, 14 Jul 2016 10:45:01 +0000 http://nimdraug.com/?p=53 10 PRINT "HELLO WORLD!" 20 GOTO 10 ]]>