Maker Faire Shenzhen 2019 had ended. It was my first exhibition in my life. This blogpost is to document what I've done during the trip for the exhibition.
It took me weeks to prepare for the event. I had to sort out the application, paperwork, etc. In addition, I had to decide which projects to be exhibited, plan for the layout of the props in the exhibition, purchasing props for exhibition, order posters, order my cards, come up a list of the equipment to be brought to the site, plan for when to go and when to leave, etc. etc. etc. I had gotten extremely busy since the day that my application of exhibition had been confirmed. :(
The preparation was a loooot of work. I barely made it on time. The organizer had provided the dimensions of the exhibition table. And here's my test exhibition setup at home with a platform made of two tables that's about the same size as the exhibition table:
I had decided to dedicate a day after the event for sightseeing. However, since I'd be exhibiting alone, touring around alone would be boring.
Luckily there's a WeChat group for oversea exhibitors. I just shouted there like an idiot and ask if anyone's planning to tour around in Shenzhen a day after the event. It turned out that there's a Japanese team interested in accompanying me. Yay! :D
We ended up having a plan for the tour in both the registration day (i.e. the day before the first day of the exhibition) and the day after the end of exhibition.
I took highspeed train from West Kowloon Station in Hong Kong SAR to Shenzhen North Station. The border control process went smoothly. And I had never traveled using the highspeed rail station in Hong Kong.
When I saw the Vibrant Express train that I was about the board on, I was excited. Despite that it's pretty much identical as other CRH380A trains in functionality, the paintings are different. And it's operated by MTR Corporation (a company in HKSAR) instead of the companies in mainland China. It's like a special snowflake.
The interior of the train didn't disappoint me either. There're TVs showcasing Hong Kong and its tourist destinations. There was only a few people traveling using the train I was in. It took a while until the train got departed tho.
However, the real disappointment started when the train got departed. As soon as the train left the station, it ended up being in a tunnel. And it's staying inside the tunnel for the entire trip. Here's a photo showing the view inside the train with nothing other than darkness outside the windows:
Its traveling speed for the entire trip was less than 200 km/h. This isn't what I was expecting for "highspeed" train. Nevertheless, it only took 20 minutes to went from West Kowloon to Shenzhen North. That's an impressively short traveling time, except that it didn't take the train waiting time into account. Depending on your origin and destination, the highspeed train may, or may not be any faster than using other kind of transit.
After having lunch close to the station, I headed to the hotel by taking metro. As I can't speak Mandarin well, it took me a bit trouble to get thru the check-in process. After that, I walked to the exhibition venue and did the registration of exhibition. Here's the entrance of the event's site:
I was allowed to perform the setup of the exhibition booth and store the exhibition props into the warehouse. However, I decided not to do that because I'd rather to do the setup right before the exhibition starts. Since I had tested the setup at home, there's no reason that the same setup wouldn't work on the site.
As there's a bit time left for the day, I gathered with the previously contacted Japanese team and toured around in Shenzhen with them. We've visited the following places:
The music park that we visited is just a park with music playing inside the entire park area. The speakers were somehow synchronized. The decoration inside the park wasn't particularly interesting. However, the view outside the park was. Here's an array of buildings outside of the park that each buildings look identical:
As for Huaqiangbei, most stores were closed by the time we arrived there because we were a bit late. Fortunately the Japanese team had managed to get what they wanted. And I've got a power adapter, a retractable USB cable and an earphone. They're of good value. :)
I was a bit surprised that most storekeepers there in Huaqiangbei couldn't speak English well. A while ago I've been to a building in Huaqiangbei that most people there could speak decent English. This led me to thought that most storekeepers in Huaqiangbei could speak English well.
After that, we got drink in a cafe. And I parted with the Japanese team, went back to hotel, took a shower and slept.
I went to the Exhibition's site about an hour early so that I could do the setup. The setup went mostly smoothly. The only issue was that I wasn't able to get the power because there's only one power socket shared between me and the booth next to me. This was quickly sorted out by contacting the organizers, which provided me a socket outlet splitter. Here's my exhibition setup:
Some of the visitors spoke English, some spoke Mandarin and a few of them were able to speak Cantonese, which's my mother tongue. It wasn't easy for me to identify which languages the visitors spoke. And I often judged that wrong. For example, many Chinese-looking visitors of my booth are actually Japanese or Korean. And a few Chinese visitors actually spoke Cantonese instead of Mandarin.
As my Mandarin was bad, quite a few of those Mandarin speaking visitors had mistaken me as Japanese. When this happened, I just pointed at the flag of China with the flag of Hong Kong SAR on the poster and explained to them that I'm from Hong Kong, China.
I actually find that it's easier for me to explain my projects in English than in Mandarin. That's probably because English is the main language I use for anything technical. I did have a problem on trying to figure out the correct technical words in Chinese (Mandarin) when I tried to explain the stuffs that I was exhibiting. Oh, of course, it's the easiest for me to explain them in Cantonese mixed with some English technical words. :P
As for the exhibition itself, it seemed to me that the kids loved the poopie game that I was exhibiting. There was a few times that the kids gathering around on the tablet that's having my poopie game running on it:
It's rather exhausting to do the exhibition alone. There's no break. I had to handle all of the visitors alone. I had compressed cracker (military ration) for lunch so that I wouldn't need to leave my booth. I only asked the staffs to take over the booth for going to toilet and fetching drinking water. Other than that I pretty much stayed in the booth during the event. It was a super busy day. :(
I joined the Maker Party after the first day of the event. It's just a normal party. It had pizza, packaged waffles, lollipop, crackers, beer and water. I wish they had non-alcoholic soft drinks tho. Here's the photo of the entrance to the party:
Since I already had dinner, I took a lollipop and that's all I had during the party. The party was mostly about socializing with other makers. So I chatted with the people inside the party.
This session reminded me of the pitching session of my first global game jam. Fortunately, I'm doing far better on this one because I'm now a less jerky person than I used to be. This party was pretty fun. I got a chance to know more about other fellow makers and learned about what they had developed and what they're making for. :)
Here's something funny happened during the party. There was a Super Mario cosplay guy in the Maker Faire. He was exhibiting just two booths away from mine. I found him in the party and tried chatting with him, only to find out that he's Japanese and he could only speak bad English and bad Mandarin. We chatted with each others mostly using simple English. With the help of photo and body language, we were still able to communicate. And we managed showed our projects to each others.
Suddenly another Japanese joined in. Thank goodness. He spoke good English albeit heavy accent. I could understand him perfectly. So he acted as a translator between the Mario guy and me. This was cool until another Japanese joined in. Then they started discussing in Japanese and started speaking less English. After that, yet another Japanese joined in and the entire conversation had turned into Japanese-only. I was like, awww. :(
Then we exchanged our cards and I moved on to chat with someone else. At least I had got the twitter of that Mario guy. xD
After the party, I got back to hotel, took a shower and slept a bit late.
It's pretty much the same as the first day. Except that there're more visitors to my booth. And I hadn't slept enough in the previous night. It was almost too much for me to handle the visitors alone. :( Here's a photo showing an overwhelming amount of visitors:
During the lunch time, I opened up another pack of compressed cracker (military ration), just like the previous day. However, there were too many visitors. It was very tough to handle the visitors while eating the crackers. It took me like 1.5 hours to finish the two crackers inside the pack because I had to stop eating multiple times for explaining my projects to my visitors. At the end of the lunch, my voice turned very bad and my throat was extremely dry. Despite that I drank a lot of water, it didn't help much. :(
The event was going to end in an hour. I was extremely tired and I needed to sleep pretty badly. There was less visitors by that time. But still, it was pretty tough to me.
After the exhibition had ended, I dismantled the booth and headed to the place of taking group photos. Here's how my booth looked like after getting dismantled:
After the event, I went to hotel and took a nap immediately. After napping for a few hours, I got out and had dinner. I felt much better after having the dinner. Then I headed back to hotel, took a shower and slept. That's the end of the day.
I had reserved this entire day for touring around in Shenzhen. The trip of this day was planned by the Japanese team that I've contacted. I took my baggage, checked-out from the hotel and gathered with the team. Here're the places that we went to:
For the anime mall, we arrived there too early. Almost all stores weren't opened. We still looked around there anyway. I've purchased an el cheapo tiny Vocaloid figure for RMB20 from an opened store, and I'm extremely disappointed. The coloring of the hair of the figure's far off.
As for the food court, it's a pretty fun one. One of the stall sold grilled insect, which I didn't dare to try. We just randomly grabbed some food there and shared with each others. Most of the food there were spicy and mala (numbing-spicy). :)
After that, we headed to high tech park. Here's a photo of an artpiece showing the bird-eye view of high tech park inside a shopping mall that we visited:
In the Xiaomi store, one of the Japanese team members purchased a new phone right on the site. Other members had purchased something else, like speaker and stuffs. I envy them. All I had got in the store was a fidget toy that costed me RMB10. I'm a poor man. :(
We didn't do much in the Huawei store because it's more expensive than the Xiaomi one.
In the cafe, each of us just grabbed a drink and we tried out the new stuffs that we've just purchased. I assembled the fidget toy. A Japanese team member had tried out the Xiaomi speaker that she had just bought and played some random music. We had fun. :)
In the evening, we went to a bar, had drinks, chicken pieces and taco and we parted.
Right before getting back to the home, I decided to check the local news in Hong Kong about the traffic. It was pretty scary. Large scale protests were happening in 11th Nov 2019 in Hong Kong, blocking the traffic and stuffs. After discussing with my family, I decided to try returning to my home anyway. If I failed, I'd get back to Huanggang and book a hotel room to stay there.
I went to Huanggang Checkpoint using metro. Then I took a cross-border bus to get back to my home. After alighting from the bus, I took a detour to avoid the police station because it's where the chaos often happen. I passed thru a road with bricks all over on it. Apparently the bricks were used for blocking the traffic and was put there by the protestors. Nevertheless, it's not that dangerous because there's no fighting between groups of people having different political ideology. In the end I managed to get back to home safely.
Goodbye Shenzhen! I'll come back again some days later! :)
The entire Maker Faire experience was pretty awesome. It was quite fun overall, including the preparation work, exhibition and the post-exhibition sightseeing. I've also made a few new friends there. :)
However, it took me a loooot of work to join the exhibition. Weeks of work had been done solely for the preparation. And the exhibition itself was extremely exhausting. It's far more exhausting than joining Global Game Jam. I'm not sure if that's because the event itself's exhausting, or the event's held outside my home town, or the combination of both. Fortunately I've taken good care of myself and ensure that I've got enough sleep and food. Despite that I've caught cold, it's still nowhere as bad as the cold spell that I've caught in my first Global Game Jam.
After the event, my mana bar has almost gone empty. I pretty much need a break. Since it's exhausting, I'm not sure if I'll be doing another exhibition next year. I guess it'd be easier if I had partner(s) for exhibition. (Oh well! As if I'd be able to get one! I only socialize with online friends that aren't in Hong Kong) Anyway, in the near future, I'll probably be laid-back for a bit and focus on watching anime and playing video games. :)
Big news! Sadale'll be exhibiting in Maker Faire Shenzhen 2019 in booth E10. It'll be my first time starting a booth for doing exhibition in my life! :)
ilo nanpa will be the main project to be exhibited. That's because it's the most successful project of Sadale. It's also my only project that had entered "mass" production stage (well, it's actually home-based "mass" production with the quantity of produced units of 40ish). I'll be introducing toki pona numeral, toki pona language and ilo nanpa device to the visitors of my booth during the event.
In addition of that, I'll probably be also showcasing some of my smaller projects, including Arduino 1602 Snake (Gaming Device), Raspberry Pi Single Key Keyboard, the Poopie game and HTML gallery generator during the exhibition.
All visitors'll be welcomed to try out the projects that I'll be exhibiting. :)
I've planned for doing an exhibition more than a year ago. That's why I had checked out Maker Faire Hong Kong 2018 to see what exactly'd be going on in Maker Faire.
Well, that was pretty much I had expected. There's exhibition and seminars and workshops. Except that the exhibition were meh. Honestly, I was quite disappointed by the exhibition of Maker Faire in Hong Kong last year.
Almost all of the exhibitors were from education institutes. Some of them were schools, while some other of them were cram schools. Despite that there're a few impressive projects among them, almost all of them were lame, dumb, meh and unimpressive. Those projects just involved using very limited technical skill. As for cram schools, they're just joining the faire for marketing their classes for kids.
Another common type of exhibitors were those who make education materials. Developing education material isn't bad per se. However, no one's going to use them for anything professional. No one ever! And what those education material doing is to raise a bunch of half-ass engineers. Same goes for cram schools. And I was hoping that I'd be able to find more exhibitors that's actually technically competent for developing something serious.
I think I'd only found like 5 non-education makers out of like 100 booths. Well, I guess learning solely from classes is a culture of Hong Kong, which's an idea that I don't quite buy into because I've become what I'm now mainly by self-learning using online resources. And the problem with those classes is that it won't take the kids far enough to be able to do everything they want to do. And that's how some, if not all of those education institutes make money. They keep teasing the kids so that they'd apply for more and more classes. :(
Despite being lame, I still planned to join Maker Faire Hong Kong this year as an exhibitor. Mainly because it'd be the most convenient to me. To my surprise, it's apparent that there'd not be any Maker Faire in Hong Kong this year. I've contacted the organizer earlier this year without any response at all. And their website is still displaying the info of the 2018's event as of the time of writing.
Since there's no Maker Faire in Hong Kong, and I still intend to do exhibition this year, I've decided to exhibit in a Maker Faire that's close to Hong Kong. The Shenzhen one is the closest one. Therefore, I decided to join the one in Shenzhen.
As a bonus, exhibition is free for individual and non-commercial team exhibitors. It's so nice of the organizer to offer booths to us for free! I'd like to thank the organizer and sponsors of the event. :)
By joining this exhibition, I'll be doing these things for the first time in my life ever!
I'm so hyped up! Can't wait to join the event! See you in booth E10 of Maker Faire Shenzhen 2019! :D
This is the second blogpost of Ilo Nanpa. You can read the first blogpost here: Ilo Nanpa (Toki Pona Calculator) - Release Announcement and Technical Details
Hey guys! I'll be distributing new units of ilo nanpa! Previously, ilo nanpa was distributed in irregular batches. From now on, I'll be shipping a batch at approximately the end of each month (unless I run out of stock).
With time-efficient production method, the time-cost of unit production is reduced by quite a lot. Therefore, I'm lowering the average donation target per unit from $30 to $20 for all of the new units produced, including international shipping fee.
For each donation made, I'd add the amount to the donation pool. For each unit shipped, I'd deduct $20 from the pool. The fund available in the donation pool will be used for giveaways, or for subsidizing those who're donating less.
For a donation of $25 per unit or above, you'll be enlisted as one of the honored donors in the official website of ilo nanpa.
If you're interested, here's the procedure of getting a unit of ilo nanpa:
If you wish to add funds to the donation pool without getting a unit of ilo nanpa, just donate to me using the donate button in the homepage of my website and contact me. The donation will be 100% used for subsidizing the recipients who are donating less or not donating (i.e. giveaway). If you wish to be named, a donation of $5 would enlist you as one of the honored donors.
The official website of ilo nanpa has been updated to show the number of units in stock, units distributed and the amount of fund available in the donation pool.
Here's the breakdown of the spending of donation for each unit:
I'd like to take this opportunity to thank all of the previous donors. With the donated amount, I've purchased new equipment, which allows me to produce ilo nanpa more efficiently.
As I'm rather new in electronics world, my current technical ability of assembling electronic parts is rather rudimentary. I've been assembling electronic devices by soldering the components onto the PCB using soldering iron one-by-one, which is extremely time consuming.
Before this project, I only had to assemble one, or perhaps a couple of prototype units for my projects. So the time inefficiency wasn't an issue. However, this had changed since the completion of the ilo napna project. I have to manually solder a handful of units of the device in order to distribute them to Toki Pona speakers. And it took me two hours to produce a unit of the device, which was dog slow. And the demand just isn't high enough to justify outsourcing the assembly process.
As the previous production method was time consuming, I looked into more time-efficient production alternatives. After some Google-Fu, I've found that solder paste stencil-based soldering is probably the way to go for the following reasons:
I've purchased the following equipment and material for experimenting with this production method:
I've purchased a new batch of ilo nanpa boards. This time, the boards are panelized so that four units of the device can be produced for each PCB. After soldering them, I'd break up the PCB and I'll get four devices from a board. Here's the photo showing a jar of solder paste, panelized PCB and a stencil on a heat-resistant mat:
Not all components can be soldered by this technique. Only SMD components can be soldered in this way. Fortunately, most of the components of ilo nanpa are SMD components. The only components that require using soldering iron are the USB port, programming port and the battery holder.
I mostly just followed this solder stencil tutorial on Youtube. Except that I'm using hot air gun instead of reflow skillet for soldering the components onto the PCB.
Here's how I'm producing the devices using this new production method:
In step 2, since some spare PCBs are required for using the stencil, the 10 thought-to-be-useless wrong ilo musi boards that I ordered long time ago is now somehow useful. They're perfect to be used for holding the ilo nanpa PCB workpiece in place so that I can apply solder paste using the stencil easily.
At the end of step 3, here's a photo showing a work-in-progress panelized PCB. Take a close look and you'll see there's a layer of gray solder paste applied on each of its pads:
As for the hot air gun in step 5, it's empirically found that setting the air flow to 2/8 and the temperature to 3/8 works well for soldering the components.
This new production method works very well. Despite that the stencil is a bit expensive, it has cut down the production time by quite a lot. Before using this method, I produced ilo nanpa at a rate of a unit per two hours. After using this method, I managed to produce four units within 2.5 hours, with an additional 0.5 hours of setup and cleanup time.
This production method is very helpful for producing several units of electronic devices in timely manner. For a demand of 20-ish units, it seems to me that it's the go-to method for production. I'm very glad to have learned it. I'll continue be using this method for small scale production.
Hey guys. Sorry for not updating you guys about this portable game console project for an extended period of time. I have been rather busy lately.
The previous blogpost of this game console was about the Stay In game developed for the 4th Alakajam. This blogpost aims to document the update of the portable game console project since the last blogpost! :)
This project had come a long way without having an official name. From now on, "ilo musi" will be the name of this portable game console! It means "amusing device" or "playful device" or "toy" in Toki Pona language. This name is chosen mainly because it is unique, and it is meaningful. As this game console is a minimalist one, this name also map well to the ideology of minimalism of Toki Pona.
I've drawn a PCB for this project! And this is the first PCB I've ever designed in my life! I've done this PCB almost five months ago. But I didn't have the time to blog about this. :)
This PCB was designed using KiCAD. The main reason of using this PCB software is that it's FOSS. To learn drawing a PCB, I went thru the official getting started documentation of KiCAD. After going thru the tutorial, I managed to draw the PCB for the game console. It's easier than I thought it'd be. :)
I've made a mistake on designing the PCB. I messed up the pinout of the microSD card as I thought that it would be identical to full-side SD card. Then I designed the circuit based on the pin-mapping of the full-size SD card. It turns out that they're different.
Here's the pinout of full-size SD card layout in SPI mode: CS, DI, VSS1, VDD, SCLK, VSS2, DO, UNUSED, UNUSED
And here's the pinout of microSD card layout in SPI mode: UNUSED, CS, DI, VDD, SCLK, VSS, DO, UNUSED
Notice how there's an extra VSS1 in the full-size SD card. I didn't notice that and I messed up. Too bad! I realized this mistake after sending my design to the PCB fab. :'(
I asked about how much would it cost to modify the design. The PCB fab told me that it's already in production. So it wasn't possible to change the design anymore. I ordered another batch of PCB with the new design. And now I've got 10 wrong ilo musi PCBs laying around:
Oh well. Lesson learned: Review the design carefully before sending it for PCB fabrication.
With the microSD issue fixed, the current PCB is working properly. Anyway, there're still some minor issues with the PCB:
The microcontroller had been upgraded from STM32F030K6T6 to STM32F030C6T6. STM32F030C6T6 has more GPIO pins compared with STM32F030K6T6. And it is easier to upgrade to another pin-compatible microcontroller with STM32F030C6T6, which is the main reason of this change. With STM32F030C6T6, it'd be possible to upgrade the RAM and flash space of the microcontroller without modifying the PCB.
As a result of the microcontroller upgrade, the amount of spare GPIO had been increased from 12 pins to 22 pins. Now there're 22 user-accessible GPIO pins that can be accessed by the games developed for this game console! :)
In the final product, the following specs is to be expected:
The game-selection menu of ilo musi is implemented! Its purpose? You guessed it. It's used for selecting a game on the microSD card. With game selection menu, it's possible to store multiple games on the same microSD card. Then the player can choose a ROM from the microSD card and play it! The menu also load system configurations and has feature designed for the ease of game development.
As shown on the picture above, the player can choose the game using the menu. The menu can be navigated using key UP and key DOWN. Key 1 is used for starting the game, and key 2 is used for refreshing the microSD card (useful for changing the microSD card).
This portable game console supports microSD card formatted as FAT32 filesystem. The file names are shown as 8.3 filename. Directory navigation is possible.
Upon the game is selected, self-flashing would be performed. After that, the program counter would be jumped from the bootloader to the game. Then it'd be up to the game to handle what to do.
As for the procedure of new game development, first, prepare the game resources, including graphical assets and whatever needed and pack the game ROM as "DEBUGRES.IMG". After that, put the file "DEBUGRES.IMG" file somewhere on the microSD card (can be put onto the root directory). Then program the game code to the microcontroller using ISP. Then the game console would be reset. Then the developer would navigate to the directory containing the "DEBUGRES.IMG". If the file is available in the directory, the game console would not perform self-flashing and jump to the game right away. Since the self-flashing part is skipped, this allows the developer to run debugger for the source code of the game with the updated game code that the developer had just flashed using ISP without repacking the game ROM. This "DEBUGRES.IMG" feature makes the life of the game developers easier.
It is possible to perform contrast adjustment using the menu by pressing key LEFT and key RIGHT. This would adjust the brightness of the pixels on the LCD. The contrast adjustment value is stored on the option bytes of the microcontroller so that it'd persist after reboot.
Along with contrast adjustment value, the clock calibration trimming value is also stored in the option bytes. The option bytes are loaded by the menu on boot. We'll get to the clock calibration trimming value in the next section of this blogpost.
There're only two option bytes in the microcontroller. The two 5-bit calibration trimming values takes 10 bits. That leaves 6 bits for contrast adjustment, which is good enough as the range of adjustment is from -10 to +2. Needless to say, some bitwise manipulation is required to put three different values into two option bytes. And this has been taken care of. :)
In most of the cases, the internal clock just works fine. According to the datasheet of STM32F030C6T6, the main clock (HSI) of the microcontroller typically has an error of ±5% at full temperature range (and ±1% at 25°C). This 5% of error often wouldn't be a major issue. If the game is running 5% slower or faster, it'd barely be noticeable. However, for things like asynchronous communication, particularly UART, 5% of error would be an major problem. We'd want to control the error to within 2% or so for reliable UART communication. For this reason, some clock calibration mechanism is required.
I've thought about including clock calibration mechanism in the game selection menu. However, it takes quite a bit of code size for clock calibration. For this reason, I made a "game" dedicated for performing clock calibration.
A 32.768kHz crystal soldered onto the device serves as a reference clock source for performing the calibration. This crystal is assumed to have almost no error, which actually is the case because the error we're looking at would be 0.01%-ish. With this clock source, the clock calibration "game" would be able to calibrate the clock by setting the trimming values (i.e. calibration value) of the main clock (HSI) and the ADC clock (HSI14) appropriately. After that, the game would measure the frequency of the low frequency internal clock (LSI) and show it on the screen, which isn't possible to get calibrated. Finally, the calibrated values are saved to the option bytes so that it'd be loaded by the game selection menu upon the game console is booted, which makes the calibration persists across power cycles.
The software of this game console had been released!
To facilitate development of new game for this game console, I've prepared a new game template! It's a skeleton code with simple structure that would be useful for most of the games. It includes code for graphical assets loading, input handling, clean screen, frame limiting and a simple game object management library.
A few Python scripts were developed to facilitate working with custom music, graphic and ROM format of ilo musi.
The bootloader is the core of the game console. It contains the game menu and the system library of the game, which all game ROMs would depend on.
The Github repository containing the bootloader and game ROMs can be found here. Currently only the binary is released because there are probably still some bugs in the bootloader. The source code of the bootloader will be eventually made available.
Since I'm done with freelancing, I've got two day job offers. To my surprise, the employment agreements of both companies have a clause saying that the copyright of all work I do while I'm employed would go to the company. The local law here say that the copyright of the stuffs that employees do during "course of employment" would go to the employer, and it'd go to the author otherwise. It means that I'd hold the copyright of hobbyist projects that I work outside work hours. But I'm not sure if the agreement would override the law.
For the existing work that I've done on this project, the copyright is definitely mine. To avoid legal dispute, the development of this game console had been suspended since I've got the day job. I'm trying to come up with an agreement on copyright arrangement of this project with my employer. My employer had verbally agreed that I'd hold the copyright of this project. But still, the paperwork isn't done yet. Hopefully everything would go thru.
In case of non-agreement on paperwork, I could just distribute this game console anyway. Despite that limitations stated above, this game console is currently perfectly playable. So it's possible to distribute it without any further copyrightable development work. Another way to do that is to hand over this project to someone else. Someone had expressed interest in hacking on this project. So I'd imagine it wouldn't be difficult to look for contributors. I could also look for a new job. But the friendly coworkers, awesome culture and decent compensation of the company are just too much for me to give up. And this kind of clause is probably more than common in employment agreements. So switching to another job may not help at all.
Meanwhile, I think I may look for legal consultation from professional lawyer on the actual copyright ownership of hobbyist projects. I know that I've signed the employment agreement. However, it wouldn't make sense if all the stuffs I make outside work hours would be copyrighted by the employer. That way I technically wouldn't even be able to post any text or photo or video to any blog or chatroom or social media without infringing the copyright of my employer. And that's just bullshit. What I really need to know is if the employment agreement would override the local copyright law. If it doesn't, I'd be all good to work on this project without any new agreement with my current employer.
Anyway, the non-copyrightable work of this project can go on without any problem, including some testing that doesn't generate copyrightable material, production efficiency research and distribution of this game console.
I'll be continue working on this game console.
No copyrightable would be generated for these tasks. I can work on these straight away:
New copyrightable material would be generated for these tasks. I have to check for the copyright ownership of the stuffs that I work on before working on these, or I could ask someone else to do these for me:
I aim to get this project done by the end of this year (not including the emulator). Let's pray and hope the copyright crap would get resolved so that the development can resume. Stay tuned! :)
nimi mute ni pi toki pona li lon. o pilin e ni.
Good news guys! The Ilo Nanpa project is completed! It's a calculator for Toki Pona numeral.
Toki Pona is a minimalist constructed language invented by jan Sonja. It has less than 130 words. It has an obscure numbering system.
Unlike the numeral of most languages, Toki Pona Numeral is a not a base-10 numeral system. There're two numbering system in Toki Pona, they are the simple system and the complex system. Here's the simple one:
Obviously there's no point making a calculator for the simple system. Here's how the complex system work. It's similar to coin-counting. Numbers are made up by adding up existing numeral words as follows:
For example, 37 would be mute luka luka luka tu because 20+5+5+5+2 is 37.
This Ilo Nanpa calculator is designed for working with the complex numbering system of Toki Pona.
Ilo Nanpa has the following feature:
Ilo Nanpa has 16 LEDs, 9 push buttons, an en/weka (addition/subtraction) slider switch and a power slider switch. A photo of Ilo Nanpa is shown below:
The power slider switch can be used for switching between battery power and USB power. To power off the device, remove the USB and slide the slider switch to the USB position. Alternatively, remove a battery and slide the slider switch to the battery position.
As shown above, it has an LED for "weka anu ala" (negative or zero), an LED for "wan" (1), a couple LEDs for "tu" (2), three LEDs for "luka" (5), four LEDs for "mute" (20), an LED for "ali" (100), a couple of LEDs for "ali ali" (200), and a couple of LEDs for "ali ali ali ali ali" (500).
Reading the number is rather straight forward. You just add up the numbers of the lit LEDs and that's it. For example, if three "mute", two "luka", a "tu" and a "wan" lights up, that'd make "mute mute mute luka luka tu wan", which is 73. If an "ali ali ali ali ali", an "ali ali" and a "wan" lights up, that'd make "ali ali ali ali ali ali ali wan", which is 701.
If the displayed value is zero, only "weka anu ala" would be lit. For negative numbers, the shown LED would be the same as positive number, except that the LED "weka anu ala" would also be lit.
There're nine buttons (ala, wan, tu, luka, mute, ali, pana, kama, tenpo) and an en/weka (addition/subtraction) slider switch. They're used for operating Ilo Nanpa.
Resetting the value to zero - ala button
The "ala" button resets the current number to zero.
Performing Addition and Subtraction Operations - wan, tu, luka, mute, ali buttons
The buttons "wan", "tu", "luka", "mute", "ali" behaves in this way: When the slider switch is in "en" (addition) position, the button pressed would add its value to the current value. When the slider switch is in "weka" (subtraction) position, the current value would be subtracted from the value of the pressed button.
This design makes sense in Toki Pona numeral because, for example, when you're trying to add 31 to the current value, as 31 is "mute luka luka wan", you'd just slide the slider switch to "en" position and press "mute", then "luka", then "luka", then "wan". If you want to further add 3 to that number, you'd just press "tu" then "wan" after that. If you want to subtract a number from current value, you'd slide to "weka" position and type in the number with the buttons.
Saving and Loading Value - pana, kama buttons
The "pana" button saves the current value displayed on LED. The "kama" button behaves like the "wan", "tu", "luka", "mute" and "ali" buttons, except that it adds or subtracts the current value with the previously saved value depending on the slider position.
Multiplication can be performed by using "pana" and "kama" buttons. For example, if you want to compute 137x5, first you resets the value to zero using "ala". Then you slide the slider switch to "en" position. After that, you type in 137. Then you press "pana". Then you press "kama" four times, which is one time less than the desired multiplier. And you'd get "ali ali ali ali ali ali mute mute mute mute luka", which is 685.
The saved value of "pana" persists over power cycles.
Stopwatch and Timer - tenpo button
This is the most complicated function of Ilo Nanpa. For simplicity, let's consider only positive value for now. I'll cover negative value later.
After the "tenpo" button is pressed, Ilo Nanpa would enter timing mode. It adds or subtracts the current value by one for each second elapsed, depending on the position of en/weka slider when the timing mode started.
During timing mode: pressing "wan", "tu", "luka", "mute", "ali" and "kama" would have no effect. Pressing "tenpo" would leave timing mode without doing anything to the current value. Pressing "ala" would leave timing mode and reset the value to the one before entering timing mode. Pressing "pana" would save the current value without leaving timing mode.
If you're using Ilo Nanpa as a timer, it would be counting towards zero. When zero is reached, it would stop the timing and the "weka anu ala" LED would blink. The brightness of the LED would be higher than usual. Pressing either "tenpo" or "ala" would leave timing mode and reset the value to the one before entering timing mode. Pressing "pana" would save the current value, which is zero. Pressing all other buttons would have no effect.
If you're using Ilo Nanpa as a stopwatch, it would be counting towards the limit (i.e. 1600 for positive number). When the limit had reached, it would stop timing and the LEDs would show the limit value and blink. The brightness of the LEDs would be higher than usual. The behavior of all buttons are the same as the one during timing mode.
If timing mode is performed with a negative value, the value update would perform 20x faster, which means that the value would get updated for every 0.05 seconds instead of every 1 second. Other than that, the behavior are the same for positive and negative value.
UPDATE : some info in this section is outdated, including production time and the way to obtain a unit of this device. Please refer to this new blogpost for the updated info: Future Distribution of Ilo Nanpa with Time-Efficient Production Method
I'm interested in distributing this Ilo Nanpa device to Toki Pona speakers.
The material cost is cheap. It only costs around $5 for a unit, including shipping fee to my home. The shipping cost to the recipient would costs <$5. However, it takes me 2 hours to manually produce a unit of Ilo Nanpa, including soldering, flashing the program and quality control. That's a lot of work for producing each unit.
If you're interested in getting an Ilo Nanpa, please fill in the form in the official website of Ilo Nanpa. At this stage, I only offer this device to Toki Pona speakers. I'll personally verify if you're capable for written communication using Toki Pona by using the contact methods you provide in the form. I ask about how much you're willing to donate in the form. It's ok to fill in any amount. At this stage I mainly want to estimate the demand and the amount that the recipients are willing to donate. If you don't have any spare money, don't be ashamed to fill in 0 there. Just tell me your situation in the "sina wile toki e ijo ante, la o toki tawa mi kepeken lupa nimi ni:" text box and there's still a chance that you may get one. :) No commitment is needed to fill in the donation amount. It's understandable that one may change their mind on the amount to be donated. However, please do not deliberately lie because that would screw up my budget.
If you have the money, please kindly donate some to me as it takes a lot of time to develop and produce this device. The extra money will be used for sending units to those who're donating less, or who have no spare money to donate.
I'm not sure about the total demand of this device. If the demand is small (maybe less than 10 units), I'd be happy to manually produce the units as long as I can recover the shipping cost and material cost.
It'd be very embarrassing if the demand is between 10 units and 50 units. There's no way that I'd go for mass production, and it wouldn't be fair for me to do the work with zero labor cost. If the demand is somewhere in between 10~50 units, I'd like to get $40 for my two hours of work (shipping fee and material cost not included), which is quite expensive and I doubt anyone would be willing to spend this amount of money for this simple device. :( I don't know. Perhaps I could get another Toki Pona speaker to share the workload and help doing the soldering and send the device to other Toki Pona speakers. Of course, anyone doing that would get a share of donation for the units that they've soldered. Please contact me (Sadale) on the Toki Pona IRC channel if you're interested in helping.
If the demand is high (perhaps more 50 units), I'd possibly pay a PCB assembly to do that for me, maybe I can start a crowdfunding campaign for that. Anyway, it may not be easy to get a PCB assembly to produce this device. Unlike conventional electronic devices, this device uses unusual electronic designators. Conventionally, resistors are labeled as R1, R2, R3... Capacitors are C1, C2... LEDs or diodes are D1, D2... For this device, resistors are awen1, awen2... Capacitors are wawa1, wawa2... and LEDs are suno1, suno2... This can be a problem for PCB assembly to produce it. If I go for mass production, perhaps I have to do a bit of compromise on the designator names.
If you're interested in getting a development kit, and you're willing to cover the material and shipping fee, I'd be more than happy to send you one. That's because most of the time involved in distributing the device are spent on soldering. It'd be a good thing if you're willing to do that on your own. Of course, I'd even be happier if you're donating a bit extra for the development effort. :P Almost all components of the device are the SMD ones. Fortunately, most of them doesn't have small pitch. The only difficult part is the USB port having a pitch of around 0.65mm. The microcontroller is having a pitch of 1.27mm, which isn't difficult. Other than that, there're just a lot of 0603 components, some SMD buttons, a 3-pin male header, a battery holder and a couple of mini slider switches. They aren't difficult (to me :P) to solder at all. I'll also ship a programmer to you so that you can program the microcontroller.
The objective of this project is to experiment with working with low-end microcontroller. After some research, it's found that STM8S001J3 is one of the cheapest microcontroller in the market with a cost of only $0.2 per unit at a quantity of 10k. This microcontroller has nice amount of flash, RAM, EEPROM and peripheral. It has 8kB flash, 1kB RAM, 128 bytes EEPROM. Compared with microcontroller series like the ATTiny or the PIC ones, this one is both cheaper and better. The only shortcoming of this microcontroller I've found is the voltage range. It's a bit narrow compared with other low-end microcontrollers.
STM8S001J3 only has 8 pins, with 5 IO pins. They have another model that's a bit more expensive with 20 pins. I intentionally pick the 8 pins one to practice IO multiplexing.
Technical objective aside, this would probably be the first electronic device designed for Toki Pona language in mind.
The most interesting aspect of this project is that the microcontroller only has 5 IO pins, yet it's capable for interfacing with 16 LEDs, 9 push buttons and a slider switch. One of the 5 IO pins doesn't even have push-pull output capability. It makes the project even more challenging.
The schematics of the project is shown below. Click the image to open it in a new window:
Charlieplexing is a technique of multiplexing output pins for driving many LEDs with small number of pins.
Conventionally, an output pin can only have two states, they're either high or low. Pins on modern microcontroller often have one more state in addition of the two states, which is high-impedance state. In high-impedance state, the pin behaves as if it's disconnected from the circuit.
To perform Charlieplexing, one would list out all of the possible pin pairs of all available pins to be used for driving LEDs. For example, if I have 5 LED pins, A, B, C, D and E, the pin pairs would be AB, AC, AD, AE, BC, BD, BE, CD, CE and DE. After that, we connect two LEDs to each pin pairs. One of them is forward-biased. Another of them is reverse-biased. Since there're 10 pin pairs, 5 pins would be able to drive 10x2 = 20 LEDs.
To light up an LED, we'd set all irrelevant pin to high-impedance state, which "disconnects" the pins from the circuit. After that, we set a pin to high, another pin to low, then the desired LED would be lighted up. For example, if you wish to light up the reverse-biased LED connected to the AB pin pair, set pin C, D and E to high-impedance, then set pin B to high and pin A to low. Then the LED would light up.
For this particular microcontroller, one of the pins is not capable for high-sink output. It means that it is not possible to output the kind of high signal that's required for Charlieplexing. That would take away 4 LEDs. Therefore, this device has 16 LEDs instead of 20 LEDs.
For this device, one LED is lighted up at a time. Then it switches to another one. This continues and repeats. At high switching frequency, it gives the user an illusion of multiple LEDs being lit at the same time.
The input buttons are multiplexed using voltage divider. There're 9 buttons and a slider switch.
The slider switch is attached to a dedicated pin. One of its position is connected to Vcc via a 470k resistor. Another of them is connected to ground via a 470k resistor. A high resistance is chosen to minimize the interference with the LED circuit.
For the 9 buttons, they're divided into three groups. Each group is having three buttons. The first group is ala-wan-tu. The second group is luka-mute-ali. The third group is pana-kama-tenpo. Each group is connected to an ADC pin of the microcontroller.
The microcontroller has two pins connected to ADC out of the box. To connect the third pin to ADC, an option byte has to be programmed. With three ADC-capable pins, we can have three button groups each handling three buttons.
Each ADC pin is pulled down by a 470k resistor. A high value resistor is chosen so that it would minimize the interference with the LED circuit. When a button is pressed, the ADC pin is parallelly connected to Vcc via a 10k (ala/luka/pana), 10k+20k (wan/mute/kama), or 10k+20k+20k (tu/ali/tenpo) resistors. Holding any button would cause the Vcc resistor and the pull down resistor to form a voltage divider. The reading of the voltage divider is fed to the ADC pin of the button group. The value chosen on the Vcc side is significantly lower than the pull-down side because there's a limit of input impedance of the microcontroller. If the is input impedance is too high, the ADC wouldn't work.
Is it alright to share the same IO pin for both input and output? Yes, it is. But it's more complicated than I thought. I ran into a few issues due to the sharing of input and output pins.
Button Detection Issue
I thought that the ADC reading for each button group would simply be a voltage divider as long as I've set all output pins to high impedance state. For example, pressing "ala" would makes the ADC reading to be MAX_ADC_VALUE x 10k/(470k+10k), pressing "wan" would be MAX_ADC_VALUE x 30k/(470k+30k) and pressing "tu" would be MAX_ADC_VALUE x 50k/(470k+50k). I was mistaken.
This thought is wrong because it doesn't consider that the input pins and the output pins are sharing the same pin. It means that when a button is pressed, the Vcc connected to the 10k/30k/50k resistor would get to the ground via both the pull-down resistor of its own button group and other button groups via the Charlieplexed LED network. That's because the Charlieplexed LED network is connected to all button groups, which is pulled down to the ground. In addition, the en/weka slider is also connected to the Charlieplexed LED network. All of these would affect the ADC reading.
Due to manufacturing tolerance, the forward voltage of each LED on the Charlieplexed LED is not known. Therefore, there's no easy way to calculate the value of ADC reading when a button is pressed. For this reason, I've included ADC reading calibration mechanism in the factory mode of the firmware.
The ADC calibration scene would require the user to press a button. It records the ADC reading of the button. The operator is required to press each of the buttons for a few times. The ADC readings of each button press are averaged out and the ADC threshold values for each button are calculated and they're saved to the EEPROM of the microcontroller. After the calibration, the microcontroller is ready for detecting button presses.
It's empirically determined that the effects of holding buttons of other button groups is negligible to the ADC reading. However, the en/weka slider does have substantial effect to the ADC reading. For this reason the ADC reading calibration are to be performed for both "en" slider position and "weka" slider position.
en/weka Slider Detection Issue
Unlike other buttons, this slider is connected to either Vcc or Ground via a 470k resistor. As the resistance is high, lighting up any LED or pressing any button would affect the detection of en/weka slider for a while. For this reason, the firmware is designed in a way that it won't perform en/weka detection when any button is held. It also stops lighting up the LEDs for a short time once a while for detection of en/weka slider position.
LED display issue
Holding a button would connect Vcc to the LED network with a resistance of 10k/30k/50k. That causes some LEDs to light up.
As a workaround, a model of LED with lower brightness is chosen. It's empirically found that the one with lower brightness is less vulnerable to this issue. With this kind of LED, the brightness caused by pressing button is far lower than the LEDs lit by the display of number. Therefore, it wouldn't be a problem for normal operation at all.
Way to Go!
Since all these issues have got a solution, there isn't a problem anymore. The device works with input and output pins multiplexed! I managed to get 5 IO pins to control 16 LEDs plus 9 buttons plus a slider switch! :D
Factory mode can perform ADC reading calibration as mentioned above. In addition of that, it's possible to perform key press tests and LED brightness adjustment using this mode.
To enter factory mode, hold down "ala" on power up for 5 seconds. After that, three "mute" LEDs and the "ali" LED would light up. It means that the device is now in password mode. By pushing the correct button sequence, the user would enter factory mode. If the user had typed in a wrong button sequence, he'd be led to normal mode. This design is to prevent unintentional access of factory mode. That's because if the user had mistakenly entered factory mode, he could screw up the ADC calibration values, which would break the button detection mechanism of the device until a proper recalibration.
Please refer to the README file of official Github repository of Ilo Nanpa for understanding how to work with factory mode.
Since we've got a low pin count microcontroller, we couldn't dedicate a pin for programming and debugging. The programming pin shares the same IO pin as luka-mute-ali button group and a few LEDs. This is a problem because we need a mechanism to reprogram the microcontroller in case it's needed.
To get the microcontroller to stay in programming mode, hold "pana" key on power up. As long as the button is held, the device would stay in programming mode. Once it's release, it'd enter normal operation mode.
The pana-kama-tenpo button group is intentionally chosen as the programming button. That's because it's a bad idea to pick any other button groups. The luka-mute-ali button group is shared with the programming pin, which means that holding only of these buttons may affect the signal of programming pin. The ADC of ala-wan-tu button group is only available after the option bytes are programmed. In case the engineer had forgot to program the option bytes, the button press of ala-wan-tu wouldn't get detected. That would cause the microcontroller to get locked up and it wouldn't be possible to reprogram it anymore.
Since using any of the other button groups is a bad idea, the pana-kama-tenpo group is chosen as the programming button group.
Let's not worry about debugging. It just isn't possible to spare a pin for debugging, unfortunately.
By the way, when I was trying to implement this mode, I screwed up a few times and permanently locked up a couple of microcontrollers. I had to throw them away and solder a new microcontroller onto the PCB. :(
This is the second PCB I've designed. The first one was for ilo musi (the game console that I had been developing). In fact, the third prototype of ilo musi is mostly completed. It's soldered on a PCB. I've never got the time to blog about it, tho.
The PCB was designed using KiCad. I use it mainly because it's free. As a bonus, it's open source. :)
The PCB of Ilo Nanpa is 50mmx50mm. I keep it small because some PCB fab offers a cheaper price for 50mmx50mm boards. I ordered 10 boards for $4 (shipping fee not included), and somehow they delivered 18 boards to me. :D
The PCB is a double layer one. There's a layer on the frontside of the board and another layer on the backside.
Other than that, there's nothing very interesting about the PCB of this project.
I've learned quite a lot from this Ilo Nanpa project, including:
This is also my first completed electronic project having a PCB! :)
Now the Ilo Nanpa project is officially completed. All I need to do is to distribute the device. :)
I'll continue to work on ilo musi, which is the game console project that I had been working on and blogging about. See you!