Nothing to see here ...A blog about hacking, programming, astronomy, and other unrelated stuff2022-05-09T07:27:03+02:00Jean-Christophe Ronaurn:md5:4aca13830534db85deafa89a62b675acDotclearOpenTama: an open source reference design for MCUGotchi !urn:md5:74b9fdd404a6a18fae49fec9a3df17882022-04-22T12:04:00+02:002022-04-24T22:55:19+02:00JCPCB DesignEmulatorOpenTamaOSHSTM32Tamagotchi<p>Last year, I introduced <a href="http://blog.rona.fr/post/2021/08/04/Spreading-virtual-life-everywhere"><strong>MCUGotchi</strong></a>, a Tamagotchi P1 emulator for microcontrollers, that worked on an STM32F0 development board. Today, I am pleased to announce the support of a new board in MCUGotchi: <strong>OpenTama</strong> !</p>
<p><a href="http://blog.rona.fr/public/OpenTama_Li.jpg" title="OpenTama_Li.jpg, avr. 2022"><img src="http://blog.rona.fr/public/.OpenTama_Li_m.jpg" alt="OpenTama_Li.jpg, avr. 2022" style="display:table; margin:0 auto;" title="OpenTama_Li.jpg, avr. 2022" /></a></p> <p>OpenTama is an <strong>open source</strong> development board created by <a href="https://www.sparkr.tech/en">Sparkr</a>, <a href="http://blog.rona.fr/post/2022/01/31/Introducing-Sparkr">the company I co-founded</a>. It has been specifically designed for MCUGotchi using <a href="https://www.kicad.org/">KiCad</a> and has everything a virtual pet needs, and even more, in a small and nice form factor.<br />
It features:</p>
<ul>
<li>a low-power STM32L072CBT MCU</li>
<li>either a backlit 128x64 LCD UC1701x or a 128x64 OLED SSD1306 display</li>
<li>an RGB LED for notifications</li>
<li>a piezoelectric speaker</li>
<li>a 1000mAh battery</li>
<li>a USB C connector for data and charging</li>
<li>three buttons</li>
</ul>
<p>Being an open source hardware design, anyone can manufacture his/her own board. Furthermore, all components have been placed on the top side of the board, so that the assembly as well can be performed by EMS such as JLCPCB, even for small quantities (references for the various parts are included in the project).
<br />
<br /></p>
<p>Regarding the software side, MCUGotchi has been enhanced with various functionalities, mainly:</p>
<ul>
<li>FAT16 storage for the ROMs and saves, seen as Mass Storage Device from a computer</li>
<li>Auto save</li>
<li>Sound support</li>
<li>RGB LED notification support</li>
<li>Battery indicator</li>
<li>Low battery detection</li>
<li>Auto power-off if no ROM is detected</li>
<li>Firmware upgrade</li>
</ul>
<p>There is also a new user menu, <strong>triggered by a long press on the right button</strong>, allowing, for instance, to configure what can be configured, to enable/disable stuff, to play with emulation related settings, to save/restore your Tamagotchi or to load custom ROMs!</p>
<p>Here is a quick video showing MCUGotchi running on the OpenTama board:</p>
<div align="center" ><iframe width="560" height="315" src="https://www.youtube.com/embed/EqYy_0zs9ZY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div>
<p>That being said, OpenTama is not limited to the MCUGotchi firmware, and is also intended to be used as a development board to learn embedded programming. For instance, I would love to see an original open source virtual pet running on OpenTama!</p>
<p>The full KiCad project, including the schematics and the PCB layout, along with the instructions to make your own, are available on GitHub <a href="https://github.com/Sparkr-tech/opentama">there</a>, and are distributed under the open hardware CERN-OHL-S v2 license.<br />
As a reminder, MCUGotchi is also available on GitHub <a href="https://github.com/jcrona/mcugotchi">there</a>.</p>
<p>If you would like to get an OpenTama board, but do not want to make it yourself, please let us know <a href="https://forms.gle/mXbyqJfZShEEEwWt6">there</a>. Depending on the demand, we are considering a small crowd-funding campaign to produce a batch.</p>
<p>If you want to know more about <strong>Sparkr</strong>, fell free to check out our website <a href="https://www.sparkr.tech/en" title="https://www.sparkr.tech/en">https://www.sparkr.tech/en</a> and/or contact us at <a href="mailto:%63%6f%6e%74%61%63%74%40%73%70%61%72%6b%72%2e%74%65%63%68">contact@sparkr.tech</a>!</p>Introducing Sparkrurn:md5:514c83407947858a09ea7b55824665f42022-01-31T12:00:00+01:002022-04-24T22:34:35+02:00JCGeneral <p>Today I am very proud to announce the beginning of a new professional adventure!</p>
<p><a href="https://www.sparkr.tech/en" title="https://www.sparkr.tech/en"><img src="http://blog.rona.fr/public/.sparkr-web_m.png" alt="sparkr-web.png, janv. 2022" style="display:table; margin:0 auto;" title="sparkr-web.png, janv. 2022" /></a></p>
<p>My business partner, Damien Tronchère, and I just launched <strong>Sparkr</strong>, our consulting activity for startups and other tech companies, to support them in transforming their ideas into industrialized products.</p>
<p>Leveraging our experience as program managers in the development and industrialization of consumer electronics products, in areas such as IOT, Android smartphones and tablets or even blockchain, we offer our expertise at all stages of the process:</p>
<ul>
<li>technical definition of products (software, electronic and mechanical architecture)</li>
<li>development and realization of POC and prototypes</li>
<li>development of key features</li>
<li>production of pre-series</li>
<li>certifications</li>
<li>mass production</li>
</ul>
<p>Fell free to check out our website <a href="https://www.sparkr.tech/en" title="https://www.sparkr.tech/en">https://www.sparkr.tech/en</a>, and do not hesitate to spread the word and/or contact us at <a href="mailto:%63%6f%6e%74%61%63%74%40%73%70%61%72%6b%72%2e%74%65%63%68">contact@sparkr.tech</a> !</p>After MCUGotchi, here is PebbleGotchi !urn:md5:9fbc34d29b6f834feb73d222ece6be7c2021-08-28T15:03:00+02:002022-04-24T22:34:48+02:00JCProgrammingEmulatorPebbleTamagotchi<p>Few weeks ago, I developed <strong>TamaLIB</strong>, a hardware/OS agnostic Tamagotchi P1 emulator library, that allowed me to create a Tamagotchi P1 ROM exploration tool called <strong>TamaTool</strong> that targets desktop computers, and a MCU oriented Tamagotchi P1 emulator called <strong>MCUGotchi</strong> (see my <a href="http://blog.rona.fr/post/2021/08/04/Spreading-virtual-life-everywhere">previous post</a> for more information).</p>
<p>Now, let me introduce <strong>PebbleGotchi</strong>, a Tamagotchi P1 emulator for the Pebble smartwatches !</p>
<p><a href="http://blog.rona.fr/public/PebbleGotchi.jpg" title="PebbleGotchi.jpg, août 2021"><img src="http://blog.rona.fr/public/.PebbleGotchi_m.jpg" alt="PebbleGotchi.jpg, août 2021" style="display:table; margin:0 auto;" title="PebbleGotchi.jpg, août 2021" /></a></p> <p>PebbleGotchi runs as a Pebble app, but cannot stay in background as its size exceeds the limit of 10kB allowed for a background worker. However, it saves its state on exit, and restores it on start, meaning that you can safely close it.</p>
<p>PebbleGotchi currently supports the Pebble Time and Pebble Time Steel. It might work on the Pebble Time Round but the layout needs to be adjusted.</p>
<p>PebbleGotchi will not be available on the Rebble store as it needs to include a <strong>Tamagotchi P1 ROM</strong> to work, and this cannot be freely distributed. Instead, it should be built from the sources and manually installed (more information and instructions <a href="https://github.com/jcrona/pebblegotchi">there</a>).
<br />
<br /></p>
<p>You can find all projects, including PebbleGotchi, on GitHub:</p>
<ul>
<li><a href="https://github.com/jcrona/pebblegotchi">PebbleGotchi</a></li>
<li><a href="https://github.com/jcrona/tamalib">TamaLIB</a></li>
<li><a href="https://github.com/jcrona/tamatool">TamaTool</a></li>
<li><a href="https://github.com/jcrona/mcugotchi">MCUGotchi</a></li>
</ul>
<p>Feel free to check them out !</p>Spreading virtual life everywhereurn:md5:bd13c6fc5dc044f33beca04d3227c3302021-08-04T17:42:00+02:002022-04-24T22:35:00+02:00JCProgrammingEmulatorSTM32Tamagotchi<p>Few weeks ago, I found my old Tamagotchi P1 in some old stuff I had, and I wondered if somehow someone hacked it. After some research, I found out that the ROM has been successfully extracted from the picture of a die, and that it could be run on some MAME emulator.
But I really wanted to play around with the ROM, and wondered if it would be possible to run it on an embedded system, like a Smartwatch or an STM32 MCU based board.</p>
<p>So to satisfy my curiosity I decided to develop my own Tamagotchi P1 emulator !</p>
<div align="center"><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><img src="http://blog.rona.fr/public/TamaTool3.png" alt="TamaTool3.png, juil. 2021" title="TamaTool3.png, juil. 2021" /></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><a href="http://blog.rona.fr/public/MCUGotchi.jpg" title="MCUGotchi.jpg, août 2021"><img src="http://blog.rona.fr/public/.MCUGotchi_m.jpg" alt="MCUGotchi.jpg, août 2021" title="MCUGotchi.jpg, août 2021" /></a></p>
</div></div>
<p><br />
<br /></p> <h2>What's inside a Tamagotchi</h2>
<p>The original Tamagotchi, also referred to as P1, was released in 1996 by Bandai, and featured:</p>
<ul>
<li>an E0C6S46 Epson MCU that runs at 32,768 kHz</li>
<li>a B/W LCD made of 32x16 pixels and 8 separate icons</li>
<li>three user buttons</li>
<li>a reset button</li>
<li>a piezoelectric speaker</li>
</ul>
<p>Luckily, the technical manual for the E0C6S46 MCU was available online directly from <a href="https://download.epson-europe.com/pub/electronics-de/asmic/4bit/62family/technicalmanual/tm_6s46.pdf">Epson's website</a>, and was basically all I needed to start writing an emulator...
<br />
<br /></p>
<h2>Desktop emulation</h2>
<p>I decided to begin with a desktop application, developed from scratch specifically for the Tamagotchi, with portability in mind. To be more specific, I divided it in two parts:</p>
<ul>
<li><strong>TamaLIB</strong> is a self-contained hardware/OS agnostic Tamagotchi P1 emulation library. It handles everything related to the actual emulation (CPU and board), relying on a user defined abstraction layer (HAL) for hardware/OS related operations like graphics, audio, clock, and so on.</li>
<li><strong>TamaTool</strong> is a cross-platform frontend for TamaLIB, while also being a HAL implementation example. It is an exploration tool featuring a realtime RAM editor, an ASM debugger and an I/Os monitor, allowing to play around with the Tamagotchi P1 ROM.</li>
</ul>
<p>As usual, you can find both projects, along with the instructions to build and use them, on GitHub:</p>
<ul>
<li><a href="https://github.com/jcrona/tamalib">TamaLIB</a></li>
<li><a href="https://github.com/jcrona/tamatool">TamaTool</a></li>
</ul>
<p>As a bonus, TamaTool also allows to extract data (mainly sprites) from the ROM in the form of a PNG file, that can then be modified using an image manipulation tool like GIMP, and finally imported back into the ROM. This basically allows to create custom Tamagotchis and eggs, as shown in the example below:</p>
<div align="center"><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><a href="http://blog.rona.fr/public/Custom_ROM1.png" title="Custom_ROM1.png, août 2021"><img src="http://blog.rona.fr/public/.Custom_ROM1_m.png" alt="Custom_ROM1.png, août 2021" /></a></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><img src="http://blog.rona.fr/public/.arrow_t.png" alt="arrow.png, juil. 2021" /></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><a href="http://blog.rona.fr/public/Custom_ROM2.png" title="Custom_ROM2.png, août 2021"><img src="http://blog.rona.fr/public/.Custom_ROM2_m.png" alt="Custom_ROM2.png, août 2021" /></a></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><img src="http://blog.rona.fr/public/.arrow_t.png" alt="arrow.png, juil. 2021" /></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><a href="http://blog.rona.fr/public/Custom_ROM3.png" title="Custom_ROM3.png, août 2021"><img src="http://blog.rona.fr/public/.Custom_ROM3_m.png" alt="Custom_ROM3.png, août 2021" /></a></p>
</div></div>
<p>TamaTool supports Linux, Windows (with some limitations) and MacOS. Binary releases are provided <a href="https://github.com/jcrona/tamatool/releases">here</a>.<br />
Android support is planned, but a dedicated application without libSDL2 will probably be more efficient.</p>
<p>For those who wonder, the shell is a picture of a my own P1, and the background image is actually a high-res scan of its background that I filtered and enhanced using GIMP to make it look more even:</p>
<div align="center"><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><a href="http://blog.rona.fr/public/background-original.jpg"><img src="http://blog.rona.fr/public/.background-original_m.jpg" alt="background-original.jpg, juil. 2021" /></a></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><img src="http://blog.rona.fr/public/.arrow_t.png" alt="arrow.png, juil. 2021" /></p>
</div><div style="display: inline-block; height: 100%; vertical-align: middle;">
<p><img src="http://blog.rona.fr/public/background.png" alt="background.png, juil. 2021" /></p>
</div></div>
<p><br />
<br /></p>
<h2>A note regarding timing accuracy</h2>
<p>While I was developing TamaTool and TamaLIB, I noticed that three factors were involved in the emulation speed of the ROM:</p>
<ul>
<li>the duration of CPU instructions</li>
<li>a 1 Hz timer</li>
<li>a 256 Hz timer</li>
</ul>
<p>My goal being that the emulation speed perceived by the user matched the one of a real Tamagotchi, I experimented with those factors to find the right constraints, while knowing the less flexible solution that would do the job would be a cycle-accurate emulation. I found out that the CPU speed was mainly responsible for the speed of the animations and UI, the 1 Hz timer for measuring the passing of time, and the 256 Hz timer for user input polling and sound output.</p>
<p>The 1 Hz and 256 Hz timers can be easily emulated since they require an accuracy of 1 s and around 4 ms respectively. However, a real Tamagotchi runs at 32,768 kHz and a real CPU instruction takes between 5 and 12 cycles to be executed, meaning that the instruction should take between 153 and 366 us to be accurate, which is pretty low and requires a high-resolution clock available on the platform running the emulator. These timings were achievable on a desktop computer, but would be harder to match on embedded systems, especially when other stuff, like updating the screen, could delay the emulation. That being said, the animations and UI transitions do not visually appear to have timings that require such a high granularity. That means the perceived speed should feel real as long as the total elapsed time was correct, with respect to the consumed CPU cycles, even if it was not at the instruction level.</p>
<p>I experimented with several implementations, but found out that the best approach was to:</p>
<ol>
<li>keep an internal tick counter storing exactly how much CPU cycles have passed</li>
<li>implement the various timers using that counter as reference</li>
<li>make sure the total elapsed time since the beginning of the emulation matched that counter as closely as possible by waiting (if needed) after each executed instruction the necessary amount of time</li>
</ol>
<p>This solution had the advantage of allowing the emulation flow to be flexible while accurate, slowing down by itself if it was too fast at some point, or speeding up to catch up if it was too slow. After some tests, I found out that an accurate clock with a resolution of 1 ms was enough to have a "realtime" experience.</p>
<p>So I had a robust emulation, but what about the initial goal of running the Tamagotchi code on an embedded system ?
<br />
<br /></p>
<h2>MCUGotchi</h2>
<p>I had a <a href="https://www.st.com/en/evaluation-tools/32f072bdiscovery.html">STM32F072 discovery board</a> laying around, so I just needed a cheap SSD1306 OLED screen and two buttons (the board already has one) to make the perfect setup to test an embedded implementation of TamaLIB. Few lines of code later, <strong>MCUGotchi</strong> was born !</p>
<p>Right now, MCUGotchi does not have sound support, but everything else works as expected, exactly like a real Tamagotchi P1 would. The board runs at 48 MHz, which is more than enough for a full speed CPU emulation. The systick feeding TamaLIB has a granularity of 100 us, and refreshing the OLED screen does take some time, but thanks to the allowed flexibility explained above, nothing can be perceived by the user. The OLED screen has a resolution of 128x64 pixels, so I had to make some 8x8 icons from scratch for the various actions provided to the user, while the pixels of the original dot matrix are represented by 3x3 squares.</p>
<p>Here is a quick video showing MCUGotchi running on the board:</p>
<div align="center" ><iframe width="560" height="315" src="https://www.youtube.com/embed/ZgO-gPx6IZI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></div>
<p>MCUGotchi aims at being an implementation example of TamaLIB's abstraction layer running on various microcontrollers, so the build system has been written in a way that allows support for other boards in the future. Regarding the code, it is clearly STM32F0 oriented, but it uses the latest version of the STM32Cube library for STM32F0, whose calls are theoretically compatible with other STM32Cube libraries. This means that the code should already run on other STM32 MCUs with minor adjustments.</p>
<p>Like TamaLIB and TamaTool, MCUGotchi is open-source and available on GitHub <a href="https://github.com/jcrona/mcugotchi">there</a>, where you will also find more information regarding how to build it, and how to reproduce my setup.
<br />
<br /></p>
<h2>Final words</h2>
<p>The end goal of this project is to allow anyone to run the Tamagotchi P1 code anywhere, while providing a tool to experiment with the Tamagotchi ROM. If time allows, I also plan to release an open-source board and casing specifically designed to run an MCUGotchi based firmware, mainly to be able to run custom ROMs on the go.</p>
<p>Right now, the project only supports the Tamagotchi P1 ROM, as there is no P2 ROM around. But I would really appreciate if someone could manage to dump the ROM of a P2 since I guess the boards are probably the same.</p>
<p>Again, all projects can be found on GitHub:</p>
<ul>
<li><a href="https://github.com/jcrona/tamalib">TamaLIB</a></li>
<li><a href="https://github.com/jcrona/tamatool">TamaTool</a></li>
<li><a href="https://github.com/jcrona/mcugotchi">MCUGotchi</a></li>
</ul>
<p>Feel free to check them out !</p>A 3D printed case for the ROCK64 boardurn:md5:8aaef602b3f707cfcd144fc9692da8032018-01-23T18:44:00+01:002022-04-24T22:35:23+02:00JC3D Printingrock64 <p>I recently bought a <a href="https://www.pine64.org/?page_id=7147">ROCK64</a> board because I wanted to upgrade my home made NAS (I just got the fiber at home, hence the upgrade).</p>
<p>The board is really nice, especially the 1Gbps Ethernet and USB3 ports. However, it needed a casing to be perfect, so, using Blender, I modified <a href="https://www.thingiverse.com/thing:1427797">a nice Raspberry Pi 3B case made by jayftee</a> to match the ROCK64 board.</p>
<div align="center" >
<p><img src="http://blog.rona.fr/public/.Rock64-Case2_m.jpg" alt="Rock64-Case2.jpg" title="Rock64-Case2.jpg, janv. 2018" />
<img src="http://blog.rona.fr/public/.Rock64-Case1_m.jpg" alt="Rock64-Case1.jpg" title="Rock64-Case1.jpg, janv. 2018" /></p>
</div>
<p>The main changes are:</p>
<ul>
<li>IR sensor and DC IN added</li>
<li>Slight changes for the audio jack and Ethernet port</li>
<li>Missing USB port removed</li>
<li>Size of the casing increased a little bit</li>
</ul>
<p>Feel free to check it out in <a href="https://www.thingiverse.com/thing:2767191">my Thingiverse account</a> !</p>
<p>See you soon !</p>Sniffing and decoding NFC with a DVB-T stick (RTL-SDR) and GNURadiourn:md5:8253fdd6e13c8f949fc82aa38198747b2017-10-15T20:55:00+02:002022-04-24T22:35:12+02:00JCHackingGNURadioNFCrtl-sdr<p>Several months ago, we got a new coffee dispenser machine at work that waits for an NFC tag before pouring a hot beverage. Everyone has a tag, and with this tag, we get free drinks. At first I wanted to clone it, so I played with <a href="https://www.aliexpress.com/item/PN532-NFC-RFID-module-User-Kits-For-Arduino-compatible-near-field-communication/1442329096.html">this nice and inexpensive NFC reader</a> (based on the well supported PN532 chip), but found out my tag, which is a Mifare Classic 1K from NXP (MF1 IC S50), was not vulnerable anymore to the current available cloning technique. Since I had never played with NFC before, I still wanted to get some data and see what I could do with it. So I switched to a new goal which was sniffing an NFC transaction between the coffee dispenser machine and my tag.</p>
<p><img src="http://blog.rona.fr/public/NFC-Coffe.jpg" alt="NFC-Coffe.jpg" style="display:table; margin:0 auto;" title="NFC-Coffe.jpg, oct. 2017" />
<br />
<br /></p> <p>Googling around, I quickly found the easiest way to do that was to get something like the <a href="https://store.ryscc.com/products/new-proxmark3-kit">Proxmark3 board</a>, but getting free drink from a machine that already delivers free drinks failed to convince me to buy this expensive tool. I then remembered I got an <a href="http://sdr.osmocom.org/trac/wiki/rtl-sdr">RTL-SDR</a> compatible DVB-T dongle, and started looking for a piece of software that would demodulate and decode NFC. Unfortunately I found none, so I decided to try to do it myself.
<br />
<br /></p>
<h2>How NFC works</h2>
<p>Let's first look at how NFC works. NFC uses a carrier frequency of 13,56 MHz, and provides three bit-rates within the 14kHz allowed bandwidth which are 106 kbps, 212 kbps, and 424 kbps. The communication involves either an active device and a passive device (for instance, a smartphone and an NFC tag), or two active devices (two smartphones for instance). In both cases, the first device is the initiator, and the other one is the target. Depending on the type of NFC, the modulation used, the line code on top of it, and the allowed bit-rates are not the same.</p>
<p>For the initiator to target communication:</p>
<ul>
<li>NFC Type A -> 100% ASK (also called OOK), 106 kbps, modified Miller code LSB first</li>
<li>NFC Type B -> 10% ASK, 106 kbps, NRZ-L code LSB first</li>
<li>NFC Type F -> 10% ASK, 212 kbps and 424 kbps, Manchester code MSB first</li>
</ul>
<p>For the target to initiator communication (modulation of a 847 kHz subcarrier):</p>
<ul>
<li>NFC Type A -> 100% ASK (also called OOK) , 106 kbps, Manchester code LSB first</li>
<li>NFC Type B -> BPSK, 106 kbps, NRZ-L code LSB first</li>
<li>NFC Type F -> 10% ASK, 212 kbps and 424 kbps, Manchester code MSB first</li>
</ul>
<p>The cool thing with NFC is that a passive device does not need its own power source to be able to respond. Instead, it is powered by the electromagnetic field generated by the initiator when it sends data to the target. My tag being an NFC Type A device, let's look at the line codes used for this type.</p>
<p>The modified Miller coder sends 4 symbols to the modulation layer per bit coded. So instead of sending a 0 to code a 0, and a 1 to code a 1, it sends:</p>
<ul>
<li>0111 to code a 0 if the previous bit was 0 or a Start</li>
<li>1111 to code a 0 if the previous bit was 1</li>
<li>1101 to code a 1</li>
</ul>
<p>The START of the frame is indicated by a logical 0, and its END by a logical 0 followed by a 1111 sequence.</p>
<p><img src="http://blog.rona.fr/public/MMiller-Example.png" alt="MMiller-Example.png" style="display:table; margin:0 auto;" title="MMiller-Example.png, sep. 2017" /></p>
<p>The actual bit-rate is the modulation bit-rate divided by 4.</p>
<p>The Manchester code is simpler. It codes a bit using the two possible symbol transitions:</p>
<ul>
<li>0 -> 01 (Low/High)</li>
<li>1 -> 10 (High/Low)</li>
</ul>
<p>The START of the frame is indicated by a logical 1, and its END by a 11 sequence.
When the signal is High, the carrier is modulated by the subcarrier.</p>
<p><img src="http://blog.rona.fr/public/Manchester-Example.png" alt="Manchester-Example.png" style="display:table; margin:0 auto;" title="Manchester-Example.png, sep. 2017" /></p>
<p>The actual bit-rate is the modulation bit-rate divided by 2.
<br />
<br /></p>
<h2>RTL-SDR and 13,56 MHz</h2>
<p>Now that we know how NFC works, let's see if we can demodulate it. First issue was the 13,56 MHz. My DVB-T dongle is based on the Rafael Micro R820T tuner, and has a range of 24 MHz - 1766 MHz, and anyway, most DVB-T dongles start at around 20 MHz. I found two solutions to this. The first one is to tune the DVB-T dongle to the most powerful harmonic, and hope there is enough power to demodulate the signal. The second and third harmonics, respectively 27,12 MHz and 40,68 MHz for NFC, are often good choices, but they might show some annoying distortions. Since we really are in near field (like dongle antenna between the tag and machine near), there was a good chance it would work (and it did !).
The second solution is this <a href="https://github.com/mutability/rtl-sdr/">heavily modified rtl-sdr driver</a> that allows the DVB-T dongle to go down to 13,56 MHz by disabling the tuner's PLL, thus allowing the RTL2832U chip to get some of the signal unchanged, and adjust its intermediate frequency accordingly. What happens exactly to the tuner depends on the range selected, and is well explained on the GitHub web page. Since the last commit on this fork was few years old, I created <a href="https://github.com/jcrona/rtl-sdr">my own rtl-sdr fork</a> that I try to keep in sync with the upstream drivers <a href="https://github.com/keenerd/rtl-sdr">here</a> and <a href="https://github.com/osmocom/rtl-sdr">here</a>.</p>
<p>Even if I actually started to demodulate NFC using the first solution, I still wanted to test the patch since it is always better to tune at the right frequency, and it worked great for my needs. However, it looks like the results vary a lot from dongle to dongle, so try both solutions, and pick the one that works best for you.</p>
<p>Here is the "NFC ping" of a smartphone viewed with <strong>Gqrx</strong>, using both solutions:</p>
<div align="center" >
<p><a href="http://blog.rona.fr/public/Ping-FFT-27.12MHz.png"><img src="http://blog.rona.fr/public/.Ping-FFT-27.12MHz_m.png" alt="Ping-FFT-27.12MHz.png" title="Ping-FFT-27.12MHz.png, sep. 2017" /></a>
<a href="http://blog.rona.fr/public/Ping-FFT-13.56MHz.png"><img src="http://blog.rona.fr/public/.Ping-FFT-13.56MHz_m.png" alt="Ping-FFT-13.56MHz.png" title="Ping-FFT-13.56MHz.png, sep. 2017" /></a></p>
</div>
<p>If you want to use the modified <strong>rtl-sdr</strong> driver with <strong>GNURadio</strong> and <strong>Gqrx</strong> on Ubuntu 14.04 - 16.04, without rebuilding everything yourself :</p>
<p>- Remove any source or binary of previous versions:</p>
<p><code>$ sudo apt-get purge --auto-remove gqrx</code>
<br />
<code>$ sudo apt-get purge --auto-remove gqrx-sdr</code>
<br />
<code>$ sudo apt-get purge --auto-remove gnuradio</code>
<br />
<code>$ sudo apt-get purge --auto-remove libgnuradio*</code>
<br />
<code>$ sudo apt-get purge --auto-remove libuhd003</code></p>
<p>- Add all the needed PPAs to get the latest relevant packages:</p>
<p><code>$ sudo add-apt-repository -y ppa:bladerf/bladerf (for 14.04 - 15.10 only)</code>
<br />
<code>$ sudo add-apt-repository -y ppa:ettusresearch/uhd</code>
<br />
<code>$ sudo add-apt-repository -y ppa:myriadrf/drivers</code>
<br />
<code>$ sudo add-apt-repository -y ppa:myriadrf/gnuradio</code>
<br />
<code>$ sudo add-apt-repository -y ppa:gqrx/gqrx-sdr</code>
<br />
<code>$ sudo apt-get update</code></p>
<p>- Install the latest libs and tools:</p>
<p><code>$ sudo apt-get install gqrx-sdr gnuradio</code></p>
<p>- Clone the modified <strong>rtl-sdr</strong> git, build it, and install it:</p>
<p><code>$ git clone https://github.com/jcrona/rtl-sdr.git</code>
<br />
<code>$ mkdir rtl-sdr/build</code>
<br />
<code>$ cd rtl-sdr/build</code>
<br />
<code>$ cmake ../</code>
<br />
<code>$ make</code>
<br />
<code>$ sudo make install</code></p>
<p>- Refresh ld cache:</p>
<p><code>$ sudo ldconfig</code></p>
<p>Now you can start <strong>Gqrx</strong>, select the RTL dongle, check the <strong>No limits</strong> checkbox, and verify you can go down to 13,56 MHz.</p>
<p>If you want to be sure that the modified <strong>rtl-sdr</strong> driver is in use, run:</p>
<p><code>$ ldd /usr/bin/gqrx | grep librtlsdr</code></p>
<p>You should see:</p>
<p><code>librtlsdr.so.0 => /usr/local/lib/librtlsdr.so.0 (0x00007ffb16445000)</code></p>
<p>The <strong><em>local</em></strong> folder indicates you are using the version you just built.</p>
<p>If you want to go back to the official <strong>rtl-sdr</strong> driver:</p>
<p><code>$ cd rtl-sdr/build</code>
<br />
<code>$ sudo make uninstall</code>
<br />
<code>$ sudo ldconfig</code></p>
<p>Now regarding the antenna, I used a smartphone cover I had laying around, and connected it to the dongle without any kind of matching. This is not ideal, but worked well enough for me.</p>
<p><a href="http://blog.rona.fr/public/NFC-Antenna.jpg"><img src="http://blog.rona.fr/public/.NFC-Antenna_m.jpg" alt="NFC-Antenna.jpg" style="display:table; margin:0 auto;" title="NFC-Antenna.jpg, oct. 2017" /></a>
<br />
<br /></p>
<h2>Demodulation</h2>
<p>To demodulate an NFC transaction, we need to demodulate two different signals. The first one corresponds to the initiator to target communication (the coffee dispenser machine queries to the tag), while the second one corresponds to the target to initiator communication (the tag responses to the coffee dispenser machine). The tag was an NXP Mifare Classic 1K (NCF Type A). So I knew that the machine to tag communication was OOK + modified Miller code on the 13,56 MHz carrier, while the responses were OOK + Manchester code on the 847 kHz subcarrier.</p>
<p>To demodulate the signal, I used the well known <strong>GNURadio Companion</strong> utility. Let's see how the demodulation is performed step by step (the resulting <strong>NFC.grc</strong> flow-graph is provided in the attachment section).
<br />
<br /></p>
<h3>OOK</h3>
<p>The first thing to do is to create a sample_rate <strong>Variable</strong> block (if not already there) that will be used across the chart. Let's set it to 2MHz which is enough. Let's also configure the <strong>Option</strong> block to WX GUI right away. Then we start the chart with an <strong>RTL-SDR Source</strong> block tuned to the right frequency. Let's also create a frequency <strong>Variable</strong> block for this. It is 13,56 MHz if you use the modified <strong>rtl-srd</strong> driver, 27,12 MHz for the second harmonic, or 40,68 MHz for the third harmonic.</p>
<p><a href="http://blog.rona.fr/public/GR-Step1.png"><img src="http://blog.rona.fr/public/GR-Step1.png" alt="GR-Step1.png" style="display:table; margin:0 auto;" title="GR-Step1.png, sep. 2017" /></a></p>
<p>To narrow down the signal to the bandwidth we want, we need to add a <strong>Low Pass Filter</strong> block. The expected bandwidth is 14 kHz, but the sidebands extend up to +-1.8 MHz. After a lot of testing, I found that a Hamming window with a cutoff frequency and a transition width of 400 kHz works well to get enough information to demodulate the signal without getting too much noise.</p>
<p><a href="http://blog.rona.fr/public/GR-Step2.png"><img src="http://blog.rona.fr/public/.GR-Step2_m.png" alt="GR-Step2.png" style="display:table; margin:0 auto;" title="GR-Step2.png, sep. 2017" /></a></p>
<p>At that point, we can plot the FFT (<strong>WX GUI FFT Sink</strong> block) and the signal (<strong>WX GUI Scope Sink</strong> block) to see if everything looks OK.</p>
<div align="center" >
<p><a href="http://blog.rona.fr/public/GR-Step3.png"><img src="http://blog.rona.fr/public/.GR-Step3_m.png" alt="GR-Step3.png" title="GR-Step3.png, sep. 2017" /></a>
<a href="http://blog.rona.fr/public/Ping-GR-Plot1.png"><img src="http://blog.rona.fr/public/.Ping-GR-Plot1_m.png" alt="Ping-GR-Plot1.png" title="Ping-GR-Plot1.png, sep. 2017" /></a></p>
</div>
<p>Now, to see the real signal, we need to get the magnitudes of the I/Q samples. This will give the envelope of the waveform which should be a rectangular signal for OOK. To do this we use the <strong>Complex to Mag</strong> block. We can also add a new <strong>WX GUI Scope Sink</strong> block to see the result.</p>
<div align="center" >
<p><a href="http://blog.rona.fr/public/GR-Step4.png"><img src="http://blog.rona.fr/public/.GR-Step4_m.png" alt="GR-Step4.png" title="GR-Step4.png, sep. 2017" /></a>
<a href="http://blog.rona.fr/public/Ping-GR-Plot2.png"><img src="http://blog.rona.fr/public/.Ping-GR-Plot2_m.png" alt="Ping-GR-Plot2.png" title="Ping-GR-Plot2.png, sep. 2017" /></a></p>
</div>
<p>The result looks great, but there is too much information compared to what we want. We only need a 1 bit output saying 0 or 1. To do that we can use the <strong>Binary Slicer</strong> block, but the signal needs to cross the 0 axis. The solution is to add an <strong>Add Const</strong> block to shift the signal down a little bit for the binary slicer. An offset of -0,1 or -0,15 was enough for me, but it depends on the amplitude of your signal. Then we can add a <strong>File Sink</strong> block to save the output in a file that can be plotted using the <strong>gr<sub>plot</sub>char</strong> command.</p>
<div align="center" >
<p><a href="http://blog.rona.fr/public/GR-Step5.png"><img src="http://blog.rona.fr/public/.GR-Step5_m.png" alt="GR-Step5.png" title="GR-Step5.png, sep. 2017" /></a>
<a href="http://blog.rona.fr/public/Ping-GR-Plot3.png"><img src="http://blog.rona.fr/public/.Ping-GR-Plot3_m.png" alt="Ping-GR-Plot3.png" title="Ping-GR-Plot3.png, sep. 2017" /></a></p>
</div>
<p>Looking at the raw output, we can see the "ping" preformed by the smartphone.</p>
<p><a href="http://blog.rona.fr/public/Ping-RAW.png"><img src="http://blog.rona.fr/public/.Ping-RAW_m.png" alt="Ping-RAW.png" style="display:table; margin:0 auto;" title="Ping-RAW.png, sep. 2017" /></a></p>
<p>Now, what remains is to decode the modifier Miller code, but unfortunately, there is no provided block to do so.
<br />
<br /></p>
<h3>Decoding the modified Miller code</h3>
<p>Something great about GNURadio is the ability to add custom blocks, and that's exactly what I had to do to decode the modifier Miller code. The source code of the block, called <strong>Modified Miller Decoder</strong>, is provided on my <a href="https://github.com/jcrona/gr-nfc">GitHub</a>. It works by counting the zeros and ones provided by the <strong>Binary Slicer</strong> block in order to measure the duration of the gaps (1) between the constant short pauses (0). It uses this equivalent table to compute the output:</p>
<ul>
<li>Short gap --> 0 or a Start if the previous bit was 0, a Start, or nothing</li>
<li>Short gap --> 1 if the previous bit was 1</li>
<li>Medium gap --> 1 if the previous bit was 0 or a Start</li>
<li>Medium gap --> 00 if the previous bit was 1</li>
<li>Long gap --> 01 (the previous bit is always 1)</li>
</ul>
<p>When a gap is converted, the resulting bits include the bit to which the short pause following the gap (that triggered the conversion) belongs.</p>
<p><img src="http://blog.rona.fr/public/MMiller-Example-Gaps.png" alt="MMiller-Example-Gaps.png" style="display:table; margin:0 auto;" title="MMiller-Example-Gaps.png, sep. 2017" /></p>
<p>The block output is the actual data sent by the machine in binary form, but what really matters is the console output as we will see later.</p>
<p>In order to use this block we must first build it and install it.
You first need to make sure you have <strong>SWIG</strong> installed. For Ubuntu, you just need to do:</p>
<p><code>$ sudo apt-get install swig</code></p>
<p>Then you can build and install the NFC module:</p>
<p><code>$ git clone https://github.com/jcrona/gr-nfc.git</code>
<br />
<code>$ mkdir gr-nfc/build</code>
<br />
<code>$ cd gr-nfc/build</code>
<br />
<code>$ cmake ../</code>
<br />
<code>$ make</code>
<br />
<code>$ sudo make install</code>
<br />
<code>$ sudo ldconfig</code></p>
<p>Now the <strong>Modified Miller Decoder</strong> block should be available in the GNURadio Companion interface (you need to hit the <strong>Reload Blocks</strong> button if GNURadio Companion is already running). We just need to add it between the <strong>Binary Slicer</strong> block and the <strong>File Sink</strong> block.</p>
<p><a href="http://blog.rona.fr/public/GR-Step6.png"><img src="http://blog.rona.fr/public/.GR-Step6_m.png" alt="GR-Step6.png" style="display:table; margin:0 auto;" title="GR-Step6.png, sep. 2017" /></a></p>
<p>The only thing remaining is to hit the <strong>Run</strong> button and look at the result !
<br />
<br /></p>
<h3>First attempt</h3>
<p>Testing again with my smartphone, I got on the console:</p>
<p><code>linux; GNU C++ version 5.4.0 20160609; Boost<sub>105800; UHD</sub>003.010.002.000-release</code>
<br />
<br />
<code>gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10</code>
<br />
<code>built-in source types: file osmosdr fcd rtl rtl_tcp uhd plutosdr miri hackrf bladerf rfspace airspy soapy redpitaya </code>
<br />
<code>Using device #0 Realtek RTL2838UHIDIR SN: 00000001</code>
<br />
<code>Found Rafael Micro R820T tuner</code>
<br />
<code>Exact sample rate is: 2000000.052982 Hz</code>
<br />
<code>[r82xx] Updated PLL limits to 26900000 .. 1885000000 Hz</code>
<br />
<br />
<code>Reader -> 26</code>
<br />
<code>Reader -> 26</code>
<br />
<code>Reader -> 26</code>
<br />
<code>Reader -> 26</code>
<br />
<code>Reader -> 26</code>
<br />
<code>Reader -> 26</code>
<br />
<code>>>> Done</code></p>
<p>We can see that we are now able to decode the "ping" performed by the smartphone ! Indeed, <strong>0x26</strong> is the <strong>REQA</strong> command which is used to probe for targets in range.</p>
<p>At that point, I put the antenna against the coffee dispenser machine, and looked at the output of GNURadio while I was approaching the tag. This is a part of what I got on the console:</p>
<p><code>Reader -> 50 00 57 CD</code>
<br />
<code>Reader -> 50 00 57 CD</code>
<br />
<code>Reader -> 50 00 57 CD</code>
<br />
<code>Reader -> 50 00 57 CD</code>
<br />
<code>Reader -> D3 41</code>
<br />
<code>Reader -> 93 E1 2C 13 8C EF 9B 1B 31 DD</code>
<br />
<code>Reader -> 61 50 9E 79</code>
<br />
<code>Reader -> 4F C7 DA 6E A8 79 9B DF 02</code>
<br />
<code>Reader -> D3 65 54 DD</code>
<br />
<code>Reader -> BC AE F6 EB</code>
<br />
<code>Reader -> 50 00 57 CD</code></p>
<p>Well, looking at the data, it was not at all what I was expecting. I was supposed to get a <strong>REQA</strong> (<strong>0x26</strong>) or <strong>WUPA</strong> (<strong>0x52</strong>) command, followed by the anti-collision procedure (several <strong>SELECT</strong> (<strong>0x93/0x95/0x97</strong>) commands, with some containing parts of the tag UID), but instead I had some unknown bytes, and the frames were not even aligned on 8 bits ! One good thing was the <strong>50 00 57 CD</strong> frame, which was a regular <strong>HALT</strong> command (<strong>0x50 0x00</strong>) followed by the right CRC (<strong>0x57 0xCD</strong>).</p>
<p>But still, something was missing, and it was the frame format !
<br />
<br /></p>
<h3>Frame format</h3>
<p>Hopefully I found online a <a href="https://nfc-wisp.wikispaces.com/file/view/fcd-14443-3.pdf">document</a> (final draft of the ISO 14443-3 standard) explaining how the data was formatted inside an NFC frame.
Basically, there are two types of frames:</p>
<ul>
<li>the Short frame: 7 bits, only for the <strong>REQA</strong> or <strong>WUPA</strong> commands ==> S |b0|b1|b2|b3|b4|b5|b6| E</li>
<li>the Standard frame: n x (8 bits + 1 bit of odd parity) ==> S |b0|b1|b2|b3|b4|b5|b6|b7| P |b8|b9|b10|b11|b12|b13|b14|b15| P | ... | E</li>
</ul>
<p>With that in mind, I tweaked the code of the block. The Short commands were now printed with <strong>"[]"</strong> around, the bytes followed by a wrong parity bit with <strong>"()"</strong> around, the broken bytes (less than 8 bits) with <strong>"/\"</strong> around, and the remaining bytes without anything else. I had the idea to keep the acquired raw data from the previous attempt, so I was able to easily replay them again and again in order to debug my block, and the result was clearly better:</p>
<p><code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> (50) (80) 55 /19\ </code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> (50) (80) 55 /19\ </code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 93 20</code>
<br />
<code>Reader -> 93 70 CB 82 F8 DF 6E 62 DD</code>
<br />
<code>Reader -> 61 28 67 CF</code>
<br />
<code>Reader -> 41 63 (B6) (0D) 9A (DB) 7E (05)</code>
<br />
<code>Reader -> (D3) 32 55 1B</code>
<br />
<code>Reader -> BC (57) FD (FD)</code>
<br />
<code>Reader -> (50) (80) 55 /19\ </code></p>
<p>I was able to see the expected <strong>WUPA</strong> command, followed by the anti-collision procedure (<strong>SELECT</strong> commands) ! Victory ?
Almost, because the only thing that looked good in the previous test did not anymore. Looking at the raw data, there was no doubt, the <strong>HALT</strong> frame was missing the parity bits on purpose. It was not a bug from neither my setup, nor my GNURadio block.</p>
<p>Although the standard states that the <strong>HALT</strong> command must respect the Standard frame format, I assumed that removing the parity bits was somehow allowed in some cases.</p>
<p>So I modified the algorithm in the block one last time, allowing it to properly display frames that look good without parity bits (length multiple of 8 bits), but do not with parity bits (length not multiple of 9 bits). The remaining frames that have a length multiple of 9 x 8 = 72 bits are displayed according to the parity mode of the previous frame.
<br />
<br /></p>
<h2>Final result</h2>
<p>Here is the final result I got:</p>
<p><code>linux; GNU C++ version 5.4.0 20160609; Boost<sub>105800; UHD</sub>003.010.002.000-release</code>
<br />
<br />
<code>gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10</code>
<br />
<code>built-in source types: file osmosdr fcd rtl rtl_tcp uhd plutosdr miri hackrf bladerf rfspace airspy soapy redpitaya </code>
<br />
<code>Using device #0 Realtek RTL2838UHIDIR SN: 00000001</code>
<br />
<code>Found Rafael Micro R820T tuner</code>
<br />
<code>Exact sample rate is: 2000000.052982 Hz</code>
<br />
<code>[r82xx] Updated PLL limits to 26900000 .. 1885000000 Hz</code>
<br />
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 93 20 </code>
<br />
<code>Reader -> 93 70 CB 82 F8 DF 6E 62 DD </code>
<br />
<code>Reader -> 61 28 67 CF </code>
<br />
<code>Reader -> 41 63 (B6) (0D) 9A (DB) 7E (05)</code>
<br />
<code>Reader -> (D3) 32 55 1B </code>
<br />
<code>Reader -> BC (57) FD (FD)</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 93 20 </code>
<br />
<code>Reader -> 93 70 CB 82 F8 DF 6E 62 DD </code>
<br />
<code>Reader -> 61 2C 43 89 </code>
<br />
<code>Reader -> (CF) (51) (04) 5C (CA) (83) 15 (F8)</code>
<br />
<code>Reader -> (52) (0C) (32) 1B </code>
<br />
<code>Reader -> (82) 17 (6B) (BB)</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 93 20 </code>
<br />
<code>Reader -> 93 70 CB 82 F8 DF 6E 62 DD </code>
<br />
<code>Reader -> 61 2C 43 89 </code>
<br />
<code>Reader -> (FE) F5 E4 (23) (BB) 7E (CB) 52 </code>
<br />
<code>Reader -> FE 9F (A7) (CD)</code>
<br />
<code>Reader -> 0B (4C) 4B 03 </code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> [52]</code>
<br />
<code>Reader -> 50 00 57 CD (No parity)</code>
<br />
<code>>>> Done</code></p>
<p>Let's analyze a small part of it:</p>
<p><code>Reader -> <strong>[52]</strong> ==> <strong>REQA</strong></code>
<br />
<code>Reader -> <strong>[52]</strong> ==> <strong>REQA</strong></code></p>
<p>The reader sends <strong>REQA</strong> commands to probe the field for tags.</p>
<p><code>Reader -> <strong>50 00 57 CD</strong> (No parity) ==> <strong>HALT</strong></code></p>
<p>The reader sends a <strong>HALT</strong> command to deactivate any tag in the field (the CRC <strong>57 00</strong> is OK). The <strong>REQA</strong> and <strong>HALT</strong> commands are sent in loop while there is no tag in the field.</p>
<p><code>Reader -> <strong>[52]</strong> ==> <strong>REQA</strong></code></p>
<p>The reader sends a new <strong>REQA</strong> command, but this time the tag is in the field. It is supposed to respond with an <strong>ATQA</strong>.</p>
<p><code>Reader -> <strong>93 20</strong> ==> <strong>SELECT</strong> Cascade 1 (no UID provided)</code></p>
<p>The reader detected a tag, and launches the anti-collision procedure by sending a <strong>SELECT</strong> Cascade 1 command without any bit of UID. All tags in the field are expected to respond with their respective UIDs.</p>
<p><code>Reader -> <strong>93 70 CB 82 F8 DF 6E 62 DD</strong> ==> <strong>SELECT</strong> Cascade 1 (UID provided)</code></p>
<p>The reader received the tag UID, and activates this particular tag by sending a new <strong>SELECT</strong> command, along with the UID targeted (the CRC <strong>62 DD</strong> is OK). The tag is expected to respond with a <strong>SAK</strong> command, indicating the type of the tag and if the anti-collision procedure is complete (no more UID byte available to transmit).</p>
<p><code>Reader -> <strong>61 28 67 CF</strong> ==> <strong>AUTH</strong></code></p>
<p>The reader sends an authentication request (<strong>AUTH</strong>) in order to start the ciphering procedure (the CRC <strong>67 CF</strong> is OK). The tag is expected to respond with a nonce (<strong>nT</strong>). From this point, all data will be encrypted.</p>
<p><code>Reader -> <strong>41 63 (B6) (0D) 9A (DB) 7E (05)</strong> ==> Encrypted data</code></p>
<p>The reader sends a nonce (<strong>nR</strong>) and its response (<strong>aR</strong>) to the tag. The tag is expected to answer with its response (<strong>aT</strong>). From this point the authentication procedure is finished.</p>
<p><code>Reader -> <strong>(D3) 32 55 1B</strong> ==> Encrypted data</code>
<br />
<code>Reader -> <strong>BC (57) FD (FD)</strong> ==> Encrypted data</code></p>
<p>The reader now sends Mifare commands, probably <strong>READ</strong> commands. The tag is expected to respond with the data stored in it.</p>
<p><code>Reader -> <strong>50 00 57 CD</strong> (No parity) ==> <strong>HALT</strong></code></p>
<p>The reader sends a <strong>HALT</strong> command to deactivate the tag.
<br />
<br /></p>
<p>Everything looked OK ! I was able to demodulate the coffee dispenser machine to tag communication just fine with my DVB-T dongle !
<br />
<br /></p>
<h2>What's next</h2>
<p>Obviously, this is just one half of the whole communication. I still need to demodulate the tag response to the machine. I'll add any needed custom block to the <a href="https://github.com/jcrona/gr-nfc">gr-nfc Git</a> so that everything will be in the <strong>NFC</strong> package.</p>
<p>So, to be continued ...</p>Building the OSSW firmware with GCCurn:md5:579300782274db9091f9e02f253404c02017-03-12T18:32:00+01:002022-04-24T22:35:39+02:00JCProgrammingOSSWWeloop<p>Few months ago, I got a Weloop Tommy smart-watch from work. I played with it a little bit, but quickly put it aside, until someone recently reminded me about this open source firmware called <a href="https://ossw.github.io/">OSSW</a> (the corresponding <strong>Hackaday.io</strong> project page can be found <a href="https://hackaday.io/project/4510-open-source-sportsmart-watch">here</a>). I thought it would be a great sandbox to start playing with the watch, but building the FW was only possible using Keil and Windows...</p>
<p>For this reason, I set up a fork on my Github account that has been adapted to build on Linux (or Cygwin) using GCC. It can be found <a href="https://github.com/jcrona/ossw-firmware-s120">here</a>.</p>
<p><img src="http://blog.rona.fr/public/.OSSW_m.jpg" alt="OSSW.jpg" style="display:table; margin:0 auto;" title="OSSW.jpg, mar. 2017" /></p> <p>In order to build OSSW, you will need:</p>
<ul>
<li>the <strong>nRF51 SDK</strong> from Nordic version 9.0.0 that can be found <a href="https://developer.nordicsemi.com/nRF5_SDK">here</a></li>
<li>the <strong>nrfutil</strong> python tool version 0.5.2 from <a href="https://github.com/NordicSemiconductor/pc-nrfutil">here</a></li>
<li>the <strong>Gnu GCC toolchain for ARM Cortex-M0</strong> that can be downloaded <a href="https://developer.arm.com/open-source/gnu-toolchain/gnu-rm">here</a>, or <a href="https://launchpad.net/gcc-arm-embedded/+download">here</a> for releases < 2016.</li>
</ul>
<p>I recommend to use the <strong>4_9-2014q4</strong> version since this was the one that produced the smallest code during my tests. I would have preferred the <strong>6-2017-q1-update</strong> version, but the resulting code was too big for the watch...</p>
<p>The <strong>Makefile</strong> expects to find the <strong>toolchain</strong> in the <code>../toolchain</code> folder, and the <strong>SDK</strong> in the <code>../nRF-SDK</code> folder, so I suggest to create the following tree:</p>
<pre>
OSSW
|____toolchain
|
|____nRF-SDK
|
|____ossw-firmware-s120
</pre>
<p>To build the firmware, just go in the <code>ossw-firmware-s120</code> folder, and type <code>$ make</code>.</p>
<p>It looks like the resulting firmware is working exactly like the original branch (I forked <a href="https://github.com/vaspa/ossw-firmware-s120">Vaspa's branch</a>), even if I had to fix some minor issues.
My plan is now to use that repository to add my own modifications to OSSW. To be continued...</p>Somfy and Blyss protocols added to rf-ctrlurn:md5:d6c9a5a81ecf1a3fa2de4220ce5c5c612016-11-09T19:01:00+01:002022-04-24T22:35:51+02:00JCHacking433MHzBlyssHome AutomationHome-RFrf-ctrlSomfy<p><a href="http://blog.rona.fr/public/Somfy-Blyss.jpg"><img src="http://blog.rona.fr/public/.Somfy-Blyss_m.jpg" alt="Somfy-Blyss.jpg" style="display:table; margin:0 auto;" title="Somfy-Blyss.jpg, nov. 2016" /></a></p>
<p>The <strong><a href="https://github.com/jcrona/rf-ctrl">rf-ctrl</a></strong> tool is now able to control plugs and rolling shutter controllers from the well known Somfy and Blyss brands. Regarding Somfy, only the 433,42 MHz RTS protocol is supported, but devices based on it are still widely available. Of course, most 433 MHz transmitters work at 433,92 MHz, which is obviously off compared to the 433,42 MHz used by Somfy. However, it works well enough, even if the range is a little bit smaller compared to what you could get with a proper 433,42 MHz transmitter.</p> <p>To control a Somfy device with <strong>rf-ctrl</strong>, you must pair <strong>rf-ctrl</strong> with your device first ! To do so, you need to put your device in association mode (long press on the device's button most of the time), choose the remote ID (0-255) and the device ID (1024-16777215) to use for this device (and stick to them), then send a <em><strong>Prog</strong></em> command. The device should acknowledge the reception of the pairing request somehow (a led blinking for instance).<br />
Now you should be able to control this device using the device and remote IDs you chose.</p>
<p>For instance, to send an association request:<br />
<code># rf-ctrl -p somfy -r 0xC0 -d 0x042420 -c prog</code></p>
<p>Then to control the device:<br />
<code># rf-ctrl -p somfy -r 0xC0 -d 0x042420 -c on</code></p>
<p>If you have any issue during the association, make sure that:</p>
<ul>
<li>the device ID you are using is higher than 1024</li>
<li>the device has not reach the maximum number allowed of associated remotes</li>
</ul>
<p>To reset completely the device and be sure it will accept an association request, hold its button for at least 10 seconds (around 3 seconds starts the association procedure, while around 10 seconds will reset the device).
<br />
<br /></p>
<p><strong>rf-ctrl</strong> also gains the ability to control plugs from the Blyss brand. These plugs are easy to find, at least in France. In order to use a Blyss device, you also need to associate <strong>rf-ctrl</strong> with it. To do so, put your device in association mode (long press on the device's button most of the time), choose the remote ID (0-1048575) and the device ID (0-16) to use for this device (and stick to them), then send an "<strong>ON</strong>" command. The device should acknowledge the reception of the pairing request somehow (a led blinking for instance).<br />
Now you should be able to control this device using the device and remote IDs you chose.
<br />
<br /></p>
<p>The <strong><a href="https://github.com/jcrona/ook-gpio">ook-gpio</a></strong> driver has been updated to support the new RAW bit format needed by the Somfy protocol, and since <strong><a href="https://github.com/jcrona/home-rf">Home-RF</a></strong> is just a Web UI on top of <strong>rf-ctrl</strong>, it is compatible with these new protocols as well ! All these projects can be found on <a href="https://github.com/jcrona">my GitHub</a>.</p>
<p>If you want to create a little gateway capable of controlling all these devices, among other things, check out <a href="http://blog.rona.fr/post/2016/10/22/Home-automation-with-cheap-433MHz-plugs-a-1%24-433MHz-transmitter-and-a-TP-Link-TL-WR703N-router">my previous post</a>.</p>Home automation with cheap 433MHz plugs, a 1$ 433MHz transmitter, and a TP-Link TL-WR703N routerurn:md5:d5552678975863c9c0154d94f49a00782016-10-22T17:42:00+02:002022-04-24T22:36:21+02:00JCHacking433MHzHome AutomationHome-RFrf-ctrlTPLINKWR703N<p>Two years ago, I started playing around with cheap 433MHz plugs that can be found almost everywhere. At that time, I got several from different brands, from the well known Chacon Di-O plugs, to the most obscure chinese/no-name ones, and my goal was to reverse engineer as much protocols as possible. I compiled the result into a little tool I called <strong>rf-ctrl</strong> (now available on <a href="https://github.com/jcrona/rf-ctrl">my GitHub</a>), and forgot about it.
However, this summer, I needed to find a solution to remotely control my electric heaters (not because I was cold obviously, but because I had the time to do it), and thought it was time to dig up <strong>rf-ctrl</strong> with a bit of polishing (a Web UI called <strong>Home-RF</strong>).</p>
<a href="http://blog.rona.fr/public/Blue-RF4.jpg"><img style="display:block; margin:0 auto; max-width: 100%; height: auto; width: auto\9" src="http://blog.rona.fr/public/Blue-RF4.jpg" alt="Blue-RF4.jpg" title="Blue-RF4.jpg, oct. 2016"></a>
<p><br /></p>
<h2>ON/OFF Keying (OOK)</h2>
<p>Let's first talk about OOK a little bit. Most of the cheap 433MHz plugs (but also chimes, rolling shutter controllers, thermometers ...) use the ON/OFF Keying or OOK modulation. The idea is that data are sent in binary form, by alternatively enabling and disabling the transmitter, thus the carrier frequency. I found mainly two ways of doing so:</p>
<ul>
<li>coding a 0 with an ON/OFF transition that has particular ON and OFF durations, and coding a 1 with another ON/OFF transition that has other particular ON and OFF durations</li>
</ul>
<p>Most of the plugs I found use this scheme, and this is the kind of modulation that <strong>rf-ctrl</strong> implements.
This technique, which could be seen as some kind of Manchester code, allows the receiver to easily recover the clock and sync, since the carrier frequency cannot be enabled or disabled longer than a particular amount of time. The timings for a 0 are often inverted compared to those of a 1, for instance, <strong>160µs-ON/420µs-OFF</strong> represents a <strong>0</strong> with the OTAX protocol, while <strong>420µs-ON/160µs-OFF</strong> represents a <strong>1</strong>. However, this is not systematic, and some protocols use totally different timings, for instance <strong>260µs-ON/260µs-OFF</strong> for a <strong>0</strong> and <strong>260µs-ON/1300µs-OFF</strong> for a <strong>1</strong> with the Di-O protocol.
The data part of the frame is sometimes encapsulated between a starting marker and an ending marker. These markers are also represented with an ON/OFF transition, but with different timings. The whole frame is then repeated a specific number of times, with a delay between the frames that can also be assimilated to either a starting marker without ON state, or an ending one with a long OFF state. Last thing to note is the transition order which is often ON/OFF, but can be OFF/ON as well.</p>
<ul>
<li>coding a 0 by disabling the carrier frequency for a time Tb, and coding a 1 by enabling it for the same time Tb</li>
</ul>
<p>This is actually the “real” low-level way of doing OOK things. You can even describe the previous one that way by choosing a bit-rate (1/Tb) high enough to represent the previous ON/OFF transitions by a succession of ones and zeros that will match the timings. This kind of coding is rather found in high-end devices, like old car keys and more secure plugs/rolling shutters. It was not compatible with the <a href="http://www.elro.eu/en/products/cat/home-automation/home-easy-next/transmitters2/pc-remote-control-usb-dongle">HE853 dongle</a> I had at that time, and thus is not supported by <strong>rf-ctrl</strong>. However I played with it at a point in order to control the rolling shutters and plugs from the Somfy brand, and to test TI's CC110x transceiver, but that's not the purpose of this post.
<br />
<br /></p>
<h2>Reversing the protocol of a 433MHz plug</h2>
<p>To replicate a protocol, one must understand two things. The OOK timings (physical characteristics) is the first one and the easiest, while the actual data format of the frame will be the second one.
<br />
<br /></p>
<h3>OOK timings</h3>
<p>The easiest way to capture a frame is to use a <a href="https://www.aliexpress.com/item/HOT-1Lot-1-pair-2pcs-RF-wireless-receiver-module-transmitter-module-Ordinary-super-regeneration-315-433MHZ/32267862145.html">1$ 433MHz (433,92Mhz actually) receiver</a> connected to either an oscilloscope or a digital analyzer. You will get something like this (Sumtech protocol):</p>
<a href="http://blog.rona.fr/public/OOK_da.png"><img style="display:block; margin:0 auto; max-width: 100%; height: auto; width: auto\9" src="http://blog.rona.fr/public/OOK_da.png" alt="OOK_da.png" title="OOK_da.png, oct. 2016"></a>
<p>But if you do not have this kind of receiver but have an oscilloscope laying around, you can also use a simple wire of around 17 cm (= 3x10<sup>8/(4x433x10</sup>6) = lambda/4) connected to one of the inputs ! You will get something like this, which is enough to understand the underlaying timings (Idk protocol this time):</p>
<p><a href="http://blog.rona.fr/public/OOK_scope.jpg"><img src="http://blog.rona.fr/public/.OOK_scope_m.jpg" alt="OOK_scope.jpg" style="display:table; margin:0 auto;" title="OOK_scope.jpg, oct. 2016" /></a></p>
<p>Thanks to this, you can measure the expected timings and the number of times the frame needs to be repeated. It's time to start writing down zeros and ones on a sheet of paper.
<br />
<br /></p>
<h3>Frame format</h3>
<p>Now, what remains is the actual data to send. Most of the time, a frame consists of a remote ID which is the ID of the remote that sends the frame, a device ID which is just the number of the button pressed on the remote, an action, like ON or OFF, which is most likely 1 or 0, some kind of checksum, and some fixed values. In some cases there are additional values that change every time a button is pressed. They are called rolling codes, and are found in brands like Somfy. This kind of codes are often harder to reverse, but the cheap plugs do not use that ;-). Finally, some protocols add a simple obfuscation layer on top of the frame, like a XOR for instance.
<br />
To understand a protocol, the best method remains to gather as much frames as possible, while writing down what generated them.
The first step is to determine if two frames generated by pushing the same button are indeed the same. It will most likely be the case, but if not, you need to find out which part of the frame changes. It can be a simple counter, or something more clever. Remember that if there is some kind of encryption/obfuscation, the whole frame can change because of a simple counter. Anyway, you need to scratch your head and find the solution by comparing as much frames as possible.
<br />
Assuming all frames generated by one button are the same, the next thing to do is to change one parameter at a time, and look at the result to identify the different fields. For instance, press the ON and OFF button of the same plug number, on the same remote, and compare the resulting frames. Only a small part of it should change, part that you can now identify as the action field.
<br />
Then press the ON button for another plug, and compare to the ON button for the first plug. Check that 1) the action field remains the same, 2) something else changed. This something else is probably the device ID.
You can then try to open the remote, and look for some kind of multi-switch or jumpers. You will not necessarily find something in all remotes since some will have their ID stored in an Eeprom or something like that, but if you do find something, try to change it and check the generated frames. This will most likely help to find the remote ID.
<br />
If you see a part of the frame that seems to change only when something else changes, then you might just have identified a checksum. Try to find how these bits can be computed from the other ones. It can be a for instance a simple sum, or a XOR.
Repeat the procedure until you are convinced that all those fields behave as assumed.
<br />
Now, keep in mind this is just a generic description of a 433MHz device. Some will not fit the mold and might have, for instance, more or less fields. The frame format can even be completely different.
<br />
<br />
Once the frame format understood, it's time to test ! For this you will need a 433MHz transmitter. I first used this <a href="http://www.elro.eu/en/products/cat/home-automation/home-easy-next/transmitters2/pc-remote-control-usb-dongle">HE853 USB dongle</a>, which works fine with a regular PC, but I found out it was easier to just use <a href="https://www.aliexpress.com/item/HOT-1Lot-1-pair-2pcs-RF-wireless-receiver-module-transmitter-module-Ordinary-super-regeneration-315-433MHZ/32267862145.html">this 1$ transmitter</a> connected to a Raspberry PI, a TP-Link TL-WR703N router, or any device that offers GPIOs. And this is where <strong>rf-ctrl</strong> comes in handy. It uses a back-end/front-end (transmitter driver/protocol driver) logic allowing to implement new protocols easily.
Here is how to do so:</p>
<ul>
<li>copy an existing protocol like <strong>auchan.c</strong> as <strong><my_protocol>.c</strong> and add it to the Makefile by appending <strong><my_protocol>.o</strong> to the <strong><code>OBJECTS</code></strong> variable</li>
<li>fill in the <strong><code>timing_config</code></strong> structure with the values you measured (values are expected in µs)</li>
<li>implement the <strong><code>int (*format<sub>cmd)(uint8</sub>t *data, size<sub>t data</sub>len, uint32<sub>t remote</sub>code, uint32<sub>t device</sub>code, rf<sub>command</sub>t command);</code></strong> function which is supposed to generate the final frame in the pre-allocated <strong><code>*data</code></strong> array of <strong><code>data_len</code></strong> bytes from the remote ID, the device ID and the command.</li>
<li>fill in the <strong><code>rf<sub>protocol</sub>driver</code></strong> structure with a short and long name for the protocol, the pointer to the <strong><code>format_cmd()</code></strong> function and to the <strong><code>timing_config</code></strong> structure, the max allowed remote and device IDs, and the actual parameters this protocol needs (most likely <strong><code>PARAM<sub>REMOTE</sub>ID | PARAM<sub>DEVICE</sub>ID | PARAM_COMMAND</code></strong>)</li>
<li>add your new protocol to the <strong><code>struct rf<sub>protocol</sub>driver *(protocol_drivers<a href="http://blog.rona.fr/post/2016/10/22/"></a>)</code></strong> list in <strong>rf-ctrl.c</strong></li>
</ul>
<p>That's all ! You should be able to build <strong>rf-ctrl</strong> and control your plug with it. If it does not work, do not hesitate to check the generated signal with your oscilloscope or digital analyzer.
<br />
<br /></p>
<h2>Controlling my electric heaters remotely</h2>
<p>Let's get back to the main topic. To control my heaters, I thought I would buy plugs from one of the brands I already reversed, and went to buy the "auchan" ones. Unfortunately, they were still selling 433MHz plugs under the same name, but the underlaying supplier had clearly changed. I decided to buy three of them anyway, but knew I would have to reverse yet another protocol, with the risk it might have used some kind of rolling codes... Hopefully, it did not, and was pretty straightforward to understand. For your information it's the protocol I called "auchan2".
<br />
Now regarding the actual setup, I used the well known <a href="https://wiki.openwrt.org/toh/tp-link/tl-wr703n">TP-Link TL-WR703N router</a> running <a href="https://openwrt.org/">OpenWrt</a> and a 1$ 433MHz transmitter (<a href="https://www.aliexpress.com/item/HOT-1Lot-1-pair-2pcs-RF-wireless-receiver-module-transmitter-module-Ordinary-super-regeneration-315-433MHZ/32267862145.html">again, like this one</a>) connected, through a 2V -> 5V level shifter, to the GPIO 7 of the router. I wrote the needed Makefile to build <strong>rf-ctrl</strong> as an OpenWrt package, and also created a kernel driver that generates the proper OOK signal on GPIO 7 once fed with the correct timings and data. This driver, called <strong>ook-gpio</strong>, is directly provided as an OpenWrt package on <a href="https://github.com/jcrona/ook-gpio">my GitHub</a>. Since the WR703N does not have much free space, I chose to build a special firmware for it with everything in it, removing what was useless.
Once the firmware flashed, I verified that I was indeed able to control my heaters. But to do that remotely, I had to connect trough SSH and use my command line tool, which looked like something that could have been improved. So I made a little Web UI called <strong>Home-RF</strong>, which is a little shell script that allows to control <strong>rf-ctrl</strong> by generating a web page with configurable presets. It looks like this:</p>
<div align="center" >
<p><a href="http://blog.rona.fr/public/Home-RF2.png"><img src="http://blog.rona.fr/public/.Home-RF2_m.png" alt="Home-RF2.png" title="Home-RF2.png, oct. 2016" /></a>
<a href="http://blog.rona.fr/public/Home-RF3.png"><img src="http://blog.rona.fr/public/.Home-RF3_m.png" alt="Home-RF3.png" title="Home-RF3.png, oct. 2016" /></a></p>
</div>
<p>The idea is that you can add presets for devices like plugs, rolling shutters or chimes, and they will be displayed like a remote. As a bonus, It also supports WakeOnLan compatible computers (using <strong>etherwake</strong>). There is a simple preset editor included in the interface, as well as an advanced panel that allows to manually control <strong>rf-ctrl</strong> or <strong>etherwake</strong>. <strong>Home-RF</strong> will be nicely displayed on a PC, as well as on mobile phones. It is available <a href="https://github.com/jcrona/home-rf">here on my GitHub</a>, and can be built as an OpenWrt package.
<br />
At that point, I rebuilt a firmware with <strong>Home-RF</strong> inside, and flashed it. I'm using a VPN at home, so I do not care about authentication directly in <strong>Home-RF</strong>. However, if you plan to use it remotely, do not forget to add some kind of access control on top of it (htaccess, SSH, VPN...) ! I will explain later how to use the basic authentication system of <strong>uhttpd</strong>.
<br />
<br /></p>
<h2>How-to do the same</h2>
<p>In order to build your own RF gateway, you will need:</p>
<ul>
<li>a TP-Link TL-WR703N router that you can find <a href="https://www.aliexpress.com/item/Portable-Mini-TP-LINK-150Mbps-USB-Wireless-3G-Router-WR703N-Wi-Fi-Router-For-Travel-Outdoor/32671694971.html">here</a> for instance</li>
<li>a 5V 433MHz transmitter like <a href="https://www.aliexpress.com/item/HOT-1Lot-1-pair-2pcs-RF-wireless-receiver-module-transmitter-module-Ordinary-super-regeneration-315-433MHZ/32267862145.html">this one</a></li>
<li>an N-MOSFET in enhancement mode with a threshold voltage smaller than 2V for the level shifter (I used <a href="https://cdn.sparkfun.com/datasheets/BreakoutBoards/BSS138.pdf">this BSS138</a>)</li>
<li>one 10k Ohm resistor</li>
<li>a 17,3cm long wire for the antenna</li>
<li>a 3 pins female connector with 2.54mm pitch (optional)</li>
<li>a piece of prototyping PCB</li>
<li>some wire</li>
<li>some <a href="https://en.wikipedia.org/wiki/Kapton">Kapton</a></li>
</ul>
<p>The provided instructions assume you are working on a PC running Linux.
<br />
<br /></p>
<h3>First, the hardware</h3>
<p>The schematic for the level shifter is the following:</p>
<p><a href="http://blog.rona.fr/public/2V_to_5V_LS.png"><img src="http://blog.rona.fr/public/.2V_to_5V_LS_m.png" alt="2V_to_5V_LS.png" style="display:table; margin:0 auto;" title="2V_to_5V_LS.png, oct. 2016" /></a></p>
<p>- Solder the MOSFET and the resistor to match the schematic above
<br />
- Use one pad of the PCB as Ground, and solder three wires on Output, +5V Transmitter, and GND Transmitter
<br />
- Either solder the 3 pins connector to the other end of the wires, or solder the RF transmitter directly (remove the male pins of the transmitter if any)
<br />
- Open the WR703N router, and look for the four signals below:</p>
<ul>
<li>Gnd is on a little pad, top side of the PCB</li>
<li>GPIO 7 is on R15, top side of the PCB</li>
<li>+2V is on C47 (or TP2V0), bottom side of the PCB</li>
<li>+5V is on R113, bottom side of the PCB</li>
</ul>
<div align="center" >
<p><a href="http://blog.rona.fr/public/WR703N_bottom.jpg"><img src="http://blog.rona.fr/public/.WR703N_bottom_m.jpg" alt="WR703N_bottom.jpg" title="WR703N_bottom.jpg, oct. 2016" /></a>
<a href="http://blog.rona.fr/public/WR703N_top.jpg"><img src="http://blog.rona.fr/public/.WR703N_top_m.jpg" alt="WR703N_top.jpg" title="WR703N_top.jpg, oct. 2016" /></a></p>
</div>
<p>- Solder one end of four wires on these signals, and the other end to the level shifter previously made</p>
<p><a href="http://blog.rona.fr/public/WR703N_module.jpg"><img src="http://blog.rona.fr/public/.WR703N_module_m.jpg" alt="WR703N_module.jpg" style="display:table; margin:0 auto;" title="WR703N_module.jpg, oct. 2016" /></a></p>
<p>- Solder the 17,3 cm long wire to the antenna pad of the transmitter and put Kapton everywhere to prevent any short-circuit (I tried without antenna at first, that's why it is missing on my picture)</p>
<p><a href="http://blog.rona.fr/public/WR703N_module2.jpg"><img src="http://blog.rona.fr/public/.WR703N_module2_m.jpg" alt="WR703N_module2.jpg" style="display:table; margin:0 auto;" title="WR703N_module2.jpg, oct. 2016" /></a></p>
<p>- Put the board back in its casing, use its <strong>reset</strong> hole to get the antenna out of it (you will have to bend the antenna to do so, so make sure it does not push the reset button), and close it</p>
<p>You should get something like this:</p>
<p><a href="http://blog.rona.fr/public/WR703N_antenna.jpg"><img src="http://blog.rona.fr/public/.WR703N_antenna_m.jpg" alt="WR703N_antenna.jpg" style="display:table; margin:0 auto;" title="WR703N_antenna.jpg, oct. 2016" /></a>
<br />
<br /></p>
<h3>Now, the software</h3>
<p>I attached a prebuilt Barrier Breaker (14.07) OpenWrt firmware with all the tools in it, but it is funnier to build it yourself:</p>
<p>- Create your root folder for the build, for instance <strong>my-gateway</strong>:</p>
<p><code>$ mkdir my-gateway</code></p>
<p>- Go to that folder, and checkout a Barrier Breaker OpenWrt tree (I did not try Chaos Calmer, so let me know if it works):</p>
<p><code>$ cd my-gateway</code>
<br />
<code>$ git clone -b barrier_breaker git://github.com/openwrt/openwrt.git</code></p>
<p>- Checkout <strong>rf-ctrl v0.5</strong>, <strong>Home-RF v0.6</strong> and <strong>ook-gpio v0.2</strong> (these versions are known to work, but feel free to test more recent ones):</p>
<p><code>$ git clone -b "v0.5" https://github.com/jcrona/rf-ctrl.git</code>
<br />
<code>$ git clone -b "v0.6" https://github.com/jcrona/home-rf.git</code>
<br />
<code>$ git clone -b "v0.2" https://github.com/jcrona/ook-gpio.git</code></p>
<p>- Create the packages folders in OpenWrt:</p>
<p><code>$ mkdir -p openwrt/package/utils/home-rf/files</code>
<br />
<code>$ mkdir -p openwrt/package/utils/rf-ctrl/src</code>
<br />
<code>$ mkdir -p openwrt/package/kernel/ook-gpio</code></p>
<p>- Copy the packages content:</p>
<p><code>$ cp -a home-rf/www openwrt/package/utils/home-rf/files/</code>
<br />
<code>$ cp home-rf/OpenWrt/Makefile openwrt/package/utils/home-rf/</code>
<br />
<code>$ cp rf-ctrl/* openwrt/package/utils/rf-ctrl/src/</code>
<br />
<code>$ cp rf-ctrl/OpenWrt/Makefile openwrt/package/utils/rf-ctrl/</code>
<br />
<code>$ cp -a ook-gpio/* openwrt/package/kernel/ook-gpio/</code></p>
<p>- Update external feeds in OpenWrt and add <strong>etherwake</strong> to the build system:</p>
<p><code>$ cd openwrt</code>
<br />
<code>$ ./scripts/feeds update -a</code>
<br />
<code>$ ./scripts/feeds install etherwake</code></p>
<p>- Download the attached <strong><a href="http://blog.rona.fr/public/home-rf_openwrt.config">home-rf_openwrt.config</a></strong> into the <strong>my-gateway</strong> folder, and use it:</p>
<p><code>$ cp ../home-rf_openwrt.config .config</code>
<br />
<code>$ make oldconfig</code></p>
<p>- Build the OpenWrt firmware</p>
<p><code>$ make</code></p>
<p>- You should have your firmware ready in <strong>my-gateway/openwrt/bin/ar71xx/</strong>.
<br />
<br />
If you have any issue buidling the <strong>mac80211</strong> package, it might be because the build system failed to clone the <strong>linux-firmware</strong> Git. In that case, download the <strong>linux-firmware-2014-06-04-7f388b4885cf64d6b7833612052d20d4197af96f.tar.bz2</strong> archive from <a href="https://github.com/jslink/openwrt-trunk-dl/blob/master/linux-firmware-2014-06-04-7f388b4885cf64d6b7833612052d20d4197af96f.tar.bz2">here</a>, copy it into the <strong>my-gateway/openwrt/dl/</strong> folder, and restart the build.</p>
<p>Now, you need to flash your WR703N router. If you never flashed OpenWrt before on your router, use <strong>openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-factory.bin</strong> as explained <a href="https://wiki.xinchejian.com/wiki/Install_OpenWRT_on_TPlink_WR703N">here</a>. Otherwise, use <strong>openwrt-ar71xx-generic-tl-wr703n-v1-squashfs-sysupgrade.bin</strong> with the <a href="https://wiki.openwrt.org/doc/howto/generic.sysupgrade#sysupgrade_sshterminal_upgrade_procedure">sysupgrade</a> tool.
<br />
<br /></p>
<h3>Final touch</h3>
<p>At that point, you should have your router up and running. You still need to configure it like a regular OpenWrt router, as explained <a href="https://wiki.openwrt.org/doc/howto/firstlogin">here</a>. You can, for instance, configure it in WiFi station mode, so that you can find the best place to reach all your 433MHz devices.
<br />
Once properly configured, open a browser and go to <strong>http://<your<sub>router</sub>ip>/home-rf</strong>. If everything went well, you will get the <strong>Home-RF</strong> interface ready to be configured !</p>
<p>If you want to add basic authentication to Home-RF, open an SSH connection to the router, and run the following commands on it (replace <strong><em>username</em></strong> and <strong><em>password</em></strong> by the username and password of your choice):</p>
<p><code># echo "/cgi-bin/home-rf:<strong><em>username</em></strong>:$(uhttpd -m <strong><em>password</em></strong>)" >> /etc/httpd.conf</code>
<br />
<code># /etc/init.d/uhttpd restart</code>
<br />
<br /></p>
<h2>Final words</h2>
<p>So now I'm able to control my electric heaters from my phone for around 20$, and I hope you will be able to do the same with your own 433MHz devices. All the discussed tools are available on my <a href="https://github.com/jcrona">GitHub</a>. I will be happy to extend the list of supported protocols in <strong>rf-ctrl</strong>, so feel free to add more.
<br />
If you want to play around, try the "scan" mode of <strong>rf-ctrl</strong> ! It allows to send all possible frames within a range of given remote IDs, device IDs, and protocols.
<br />
<br />
That's all for now !</p>Adding a fan to a Sanguinololu v1.3burn:md5:6f17d5324f1b524b5ccb2a77131ab3102014-09-14T14:24:00+02:002022-04-24T22:36:48+02:00JC3D PrintingPrusa i3RepRap<p>Few months ago, I completed the build of my <a href="http://reprap.org/wiki/Prusa_i3">RepRap Prusa i3</a>, and decided in the process to add a fan to it.</p>
<p><img src="http://blog.rona.fr/public/.fan_mounted_m.jpg" alt="fan_mounted.jpg" style="display:table; margin:0 auto;" title="fan_mounted.jpg, sept. 2014" /></p>
<p>There are several parts that can benefit from a fan, but since I'm exclusively printing PLA, I was mainly interested in cooling down the print itself. I easily found some nice fan mounts on <a href="http://www.thingiverse.com/">Thingiverse</a>, but I had some difficulties to find the fan connector of my Sanguinololu 1.3b. And for good reasons, since there is none. Well, not dedicated to a fan at least.</p> <p><br /></p>
<h4>A 5V to 12V PWM converter</h4>
<p>Here is a list of what I used to add a regular 12V PC chipset fan to you my Sanguinololu v1.3b (should work on v1.2 or superior) :</p>
<ol>
<li>A 2-pin 40mm 12V fan (3-pin should work too using the 12V and GND pins only)</li>
<li>An <a href="http://www.irf.com/product-info/datasheets/data/irlms2002.pdf">IRLMS2002 SMD MOSFET</a></li>
<li>A 10 kOhm SMD resistor</li>
<li>An <a href="http://www.onsemi.com/pub/Collateral/MBR0530T1-D.PDF">SMD Schottky diode</a></li>
<li>Three 2-pin connectors (one for the FAN, two for the Sanguinololu)</li>
<li>A piece of heat-shrink tube</li>
<li>Some wire</li>
<li>Some <a href="http://en.wikipedia.org/wiki/Kapton">Kapton</a></li>
</ol>
<p>The idea was to use the 5V PWM pin from the Sanguinololu to pilot the 12V fan. In order to do so, I used a simple MOSFET and a 10 kOhm pull-down resistor. I also added a flyback diode to the fan that the MOSFET is controlling. Of course, if you have a 5V fan, you just need the flyback diode.<br />
In order to have a nice connector for the fan and no piece of PCB hanging, I tried to fit everything inside the heat-shrink tube.</p>
<p>The schematic of the converter :
<a href="http://blog.rona.fr/public/Fan-Schematics.png"><img src="http://blog.rona.fr/public/.Fan-Schematics_m.png" alt="Fan-Schematics.png" style="display:table; margin:0 auto;" title="Fan-Schematics.png, sept. 2014" /></a>
<br />
<br /></p>
<h4>Building it</h4>
<p>I first soldered the diode directly on the 2-pin connector.</p>
<div align="center">
<p><a href="http://blog.rona.fr/public/IMG_20140317_113359.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_113359_m.jpg" alt="IMG_20140317_113359.jpg" title="IMG_20140317_113359.jpg, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_20140317_115021.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_115021_m.jpg" alt="IMG_20140317_115021.jpg" title="IMG_20140317_115021.jpg, sept. 2014" /></a></p>
</div>
<p>Then I soldered two of the MOSFET Drain pins on the 2-pin connector GND pin (on the other side of the connector this time).
The blue paste was some nail polish I put to isolate the 12V pin, but it did not work as expected since the heat was melting the nail polish... Eventually, I had to use some Kapton instead, but this is not shown in the pictures.</p>
<p><a href="http://blog.rona.fr/public/IMG_20140317_151757.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_151757_m.jpg" alt="IMG_20140317_151757.jpg" style="display:table; margin:0 auto;" title="IMG_20140317_151757.jpg, sept. 2014" /></a></p>
<p>The last component needed was the pull-down resistor I soldered between the Gate and Source pins.</p>
<div align="center">
<p><a href="http://blog.rona.fr/public/IMG_20140317_172754.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_172754_m.jpg" alt="IMG_20140317_172754.jpg" title="IMG_20140317_172754.jpg, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_20140317_172821.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_172821_m.jpg" alt="IMG_20140317_172821.jpg" title="IMG_20140317_172821.jpg, sept. 2014" /></a></p>
</div>
<p>Here is the final result with the protecting heat-shrink tube :</p>
<p><a href="http://blog.rona.fr/public/IMG_20140317_174624.jpg"><img src="http://blog.rona.fr/public/.IMG_20140317_174624_m.jpg" alt="IMG_20140317_174624.jpg" style="display:table; margin:0 auto;" title="IMG_20140317_174624.jpg, sept. 2014" /></a></p>
<p>To connect it to the Sanguinololu, I used two 2-pin connectors : one for the 12V and GND pins, and one for the D12 5V PWM pin (leaving one hole of the connector empty).<br />
It had be connected as follows :</p>
<p><img src="http://blog.rona.fr/public/Sanguinololu_connector.png" alt="Sanguinololu_connector.png" style="display:table; margin:0 auto;" title="Sanguinololu_connector.png, sept. 2014" />
<br />
<a href="http://blog.rona.fr/public/IMG_20140913_153431.jpg"><img src="http://blog.rona.fr/public/.IMG_20140913_153431_m.jpg" alt="IMG_20140913_153431.jpg" style="display:table; margin:0 auto;" title="IMG_20140913_153431.jpg, sept. 2014" /></a></p>
<p>I then printed these <a href="http://www.thingiverse.com/thing:168303">nice fan mount and duct</a> from Thingiverse, and mounted everything in place.</p>
<div align="center">
<p><a href="http://blog.rona.fr/public/IMG_20140913_153626.jpg"><img src="http://blog.rona.fr/public/.IMG_20140913_153626_m.jpg" alt="IMG_20140913_153626.jpg" title="IMG_20140913_153626.jpg, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_20140913_153708.jpg"><img src="http://blog.rona.fr/public/.IMG_20140913_153708_m.jpg" alt="IMG_20140913_153708.jpg" title="IMG_20140913_153708.jpg, sept. 2014" /></a></p>
</div>
<p><br /></p>
<h4>Final touch</h4>
<p>From a software point of view, the fan needed to be enabled with the proper pin in the Sanguinololu firmware.
I'm using <a href="https://github.com/kliment/Sprinter">Sprinter</a> as firmware, so I had to edit Sprinter/pins.h, and replace</p>
<p><code>#define FAN_PIN -1</code></p>
<p>by</p>
<p><code>#define FAN_PIN 4 // D12 PWM pin</code></p>
<p>in the Sanguinololu pin assignment (MOTHERBOARD == 62).
<br /></p>
<p>Once the firmware rebuilt and flashed, I had a working fan mounted on my Prusa i3 !</p>Enhanced Rovio (WowWee)urn:md5:75bb09c2c9781ecf7cd6b7d7016f0d092014-09-10T22:25:00+02:002022-04-24T22:37:09+02:00JCProgrammingRovioWowWee <p>I played a little with the discontinued <a href="http://www.wowwee.com/en/products/tech/telepresence/rovio/rovio">Rovio from WowWee</a> this week, and found out that the firmware source code has been released some times ago.</p>
<p>Several custom firmwares already exist, but I played with only one so far : <a href="https://sites.google.com/site/iosrovio/rovio-firmware">Rovio Chat custom firmware</a>. This custom firmware integrates some interesting functionalities (mainly a Network Watchdog), but I wanted to add other features, like turning ON/OFF the blue LEDs.</p>
<p>That's why I just set up a Github repository, importing the original source code (v5.03) with Rovio Chat changes on top of it as a starting point.</p>
<p>So far, I also added the following functionalities :</p>
<ul>
<li>Blue LEDs control integrated into the WEB interface</li>
<li>Incremental camera adjustment control (from Rovio Chat) integrated into the WEB interface</li>
</ul>
<p><br /></p>
<p>The repository can be found <a href="https://github.com/jcrona/rovio-fw">here</a>, and some nice building instructions <a href="http://sourceforge.net/p/rovio/wiki/Rovio%20Software/">here</a>.</p>
<p>Feel free to check it out !</p>Inside a KORG Kaossilator Prourn:md5:baf4521501de5509c09930c0263e128a2014-09-04T21:48:00+02:002022-04-24T22:37:19+02:00JCHackingKaoss Pad 3Kaossilator ProKO-1 PROKorgKP3<p>The Kaossilator Pro is a Dynamic Phrase Synthesizer/Loop recorder from KORG, and I just got mine this week !</p>
<p><img src="http://blog.rona.fr/public/korg-kaossilator-pro-352879.jpg" alt="korg-kaossilator-pro-352879.jpg" style="display:table; margin:0 auto;" title="korg-kaossilator-pro-352879.jpg, sept. 2014" /></p>
<p>However, the version I was able to find for a reasonable price is the Pro one, which is discontinued... It has been replaced by the Pro + version which looks almost the same, but offers 50 more programs.<br />
I played a little with it, but soon I wondered if it was possible to upgrade it to the "+" version. After all, both version might share the same hardware (HW) ? It is quite possible since I do not see any real improvement that would justify a entirely new HW revision. Maybe a bigger ROM to fit the new programs ?</p> <p>I tried to find some service manuals, schematics, pictures of the inside of both versions, or any other useful information, but I had no luck. Well, that's not entirely true since I found the <a href="http://elektrotanya.com/korg_kp3_sm_ver2a_kaoss_pad_dynamic_effects_sampler.pdf/download.html">service manual of the KORG Kaoss Pad 3 (KP3)</a>. The KP3 looks like a red Kaossilator Pro, only offers effects (in a more advanced way than the Kaossilator Pro would), is also discontinued, and has been replaced by a "+" version too ! So not the same product, but they might still share some HW/production related stuff/firmware layout, and we will see they do ! I also found, on <a href="http://www.korg.com/us/support/">KORG's website</a>, one firmware upgrade for the Kaossilator Pro and and one for the KP3. No firmware upgrade for the Kaossilator Pro + however (that would have helped a lot), nor for the KP3 + yet... That's pretty much what I found so far.</p>
<p>The KP3 service manual is full of interesting things : a block diagram of the device, a disassembly guide, all the schematics, the special key combinations used in production/RMA, the touchscreen calibration procedure and the BOM ! If the Kaossilator Pro and the KP3 HW are close enough, I might be able to turn mine into a KP3...</p>
<p>So now I'm currently following two paths for deeper investigations :</p>
<ul>
<li>the hardware one</li>
<li>the firmware one</li>
</ul>
<p><br /></p>
<h4>Let's start with the hardware</h4>
<p>Since I found nothing on the Kaossilator Pro hardware, it did not take long before I opened mine, so here are some pictures :</p>
<p><a href="http://blog.rona.fr/public/IMG_8417.JPG"><img src="http://blog.rona.fr/public/.IMG_8417_s.jpg" alt="IMG_8417.JPG" title="IMG_8417.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8418.JPG"><img src="http://blog.rona.fr/public/.IMG_8418_s.jpg" alt="IMG_8418.JPG" title="IMG_8418.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8419.JPG"><img src="http://blog.rona.fr/public/.IMG_8419_s.jpg" alt="IMG_8419.JPG" title="IMG_8419.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8421.JPG"><img src="http://blog.rona.fr/public/.IMG_8421_s.jpg" alt="IMG_8421.JPG" title="IMG_8421.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8423.JPG"><img src="http://blog.rona.fr/public/.IMG_8423_s.jpg" alt="IMG_8423.JPG" title="IMG_8423.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8424.JPG"><img src="http://blog.rona.fr/public/.IMG_8424_s.jpg" alt="IMG_8424.JPG" title="IMG_8424.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8425.JPG"><img src="http://blog.rona.fr/public/.IMG_8425_s.jpg" alt="IMG_8425.JPG" title="IMG_8425.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8434.JPG"><img src="http://blog.rona.fr/public/.IMG_8434_s.jpg" alt="IMG_8434.JPG" title="IMG_8434.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8436.JPG"><img src="http://blog.rona.fr/public/.IMG_8436_s.jpg" alt="IMG_8436.JPG" title="IMG_8436.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8441.JPG"><img src="http://blog.rona.fr/public/.IMG_8441_s.jpg" alt="IMG_8441.JPG" title="IMG_8441.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8442.JPG"><img src="http://blog.rona.fr/public/.IMG_8442_s.jpg" alt="IMG_8442.JPG" title="IMG_8442.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8445.JPG"><img src="http://blog.rona.fr/public/.IMG_8445_s.jpg" alt="IMG_8445.JPG" title="IMG_8445.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8448.JPG"><img src="http://blog.rona.fr/public/.IMG_8448_s.jpg" alt="IMG_8448.JPG" title="IMG_8448.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8449.JPG"><img src="http://blog.rona.fr/public/.IMG_8449_s.jpg" alt="IMG_8449.JPG" title="IMG_8449.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8450.JPG"><img src="http://blog.rona.fr/public/.IMG_8450_s.jpg" alt="IMG_8450.JPG" title="IMG_8450.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8451_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8456.JPG"><img src="http://blog.rona.fr/public/.IMG_8456_s.jpg" alt="IMG_8456.JPG" title="IMG_8456.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8458.JPG"><img src="http://blog.rona.fr/public/.IMG_8458_s.jpg" alt="IMG_8458.JPG" title="IMG_8458.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8461.JPG"><img src="http://blog.rona.fr/public/.IMG_8461_s.jpg" alt="IMG_8461.JPG" title="IMG_8461.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8465.JPG"><img src="http://blog.rona.fr/public/.IMG_8465_s.jpg" alt="IMG_8465.JPG" title="IMG_8465.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8466.JPG"><img src="http://blog.rona.fr/public/.IMG_8466_s.jpg" alt="IMG_8466.JPG" title="IMG_8466.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8469.JPG"><img src="http://blog.rona.fr/public/.IMG_8469_s.jpg" alt="IMG_8469.JPG" title="IMG_8469.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8473.JPG"><img src="http://blog.rona.fr/public/.IMG_8473_s.jpg" alt="IMG_8473.JPG" title="IMG_8473.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8475_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8477_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8479_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8485_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8451.JPG"><img src="http://blog.rona.fr/public/.IMG_8490_s.jpg" alt="IMG_8451.JPG" title="IMG_8451.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8508.JPG"><img src="http://blog.rona.fr/public/.IMG_8508_s.jpg" alt="IMG_8508.JPG" title="IMG_8508.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8512.JPG"><img src="http://blog.rona.fr/public/.IMG_8512_s.jpg" alt="IMG_8512.JPG" title="IMG_8512.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8515.JPG"><img src="http://blog.rona.fr/public/.IMG_8515_s.jpg" alt="IMG_8515.JPG" title="IMG_8515.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8519.JPG"><img src="http://blog.rona.fr/public/.IMG_8519_s.jpg" alt="IMG_8519.JPG" title="IMG_8519.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8525.JPG"><img src="http://blog.rona.fr/public/.IMG_8525_s.jpg" alt="IMG_8525.JPG" title="IMG_8525.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8526.JPG"><img src="http://blog.rona.fr/public/.IMG_8526_s.jpg" alt="IMG_8526.JPG" title="IMG_8526.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8530.JPG"><img src="http://blog.rona.fr/public/.IMG_8530_s.jpg" alt="IMG_8530.JPG" title="IMG_8530.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8532.JPG"><img src="http://blog.rona.fr/public/.IMG_8532_s.jpg" alt="IMG_8532.JPG" title="IMG_8532.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8533.JPG"><img src="http://blog.rona.fr/public/.IMG_8533_s.jpg" alt="IMG_8533.JPG" title="IMG_8533.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8539.JPG"><img src="http://blog.rona.fr/public/.IMG_8539_s.jpg" alt="IMG_8539.JPG" title="IMG_8539.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8549.JPG"><img src="http://blog.rona.fr/public/.IMG_8549_s.jpg" alt="IMG_8549.JPG" title="IMG_8549.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8555.JPG"><img src="http://blog.rona.fr/public/.IMG_8555_s.jpg" alt="IMG_8555.JPG" title="IMG_8555.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8557.JPG"><img src="http://blog.rona.fr/public/.IMG_8557_s.jpg" alt="IMG_8557.JPG" title="IMG_8557.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8560.JPG"><img src="http://blog.rona.fr/public/.IMG_8560_s.jpg" alt="IMG_8560.JPG" title="IMG_8560.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8562.JPG"><img src="http://blog.rona.fr/public/.IMG_8562_s.jpg" alt="IMG_8562.JPG" title="IMG_8562.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8566.JPG"><img src="http://blog.rona.fr/public/.IMG_8566_s.jpg" alt="IMG_8566.JPG" title="IMG_8566.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8567.JPG"><img src="http://blog.rona.fr/public/.IMG_8567_s.jpg" alt="IMG_8567.JPG" title="IMG_8567.JPG, sept. 2014" /></a>
<a href="http://blog.rona.fr/public/IMG_8569.JPG"><img src="http://blog.rona.fr/public/.IMG_8569_s.jpg" alt="IMG_8569.JPG" title="IMG_8569.JPG, sept. 2014" /></a></p>
<p>We see that the KP3 and KaossPro HW are similar, but not identical.</p>
<p>They share (only the main ICs) :</p>
<ul>
<li>the C55xx DSP from TI (TMS320VC5501PGF 300)</li>
<li>the AKM 4384ET DAC</li>
<li>the 128Mbit SDRAM</li>
</ul>
<p>They do not share :</p>
<ul>
<li>the H8S/2215C CPU : the KP3 has a <a href="http://www.renesas.com/products/mpumcu/h8s/h8s2200/h8s2215/device/HD64F2215UTE16V.jsp">HD64F2215UTE16V</a> (256KB ROM, 16KB RAM), the KaossPro has a HD64F2215CTE24V which is probably <a href="http://www.renesas.com/products/mpumcu/h8s/h8s2200/h8s2215/device/HD64F2215CUTE24.jsp">this one</a> (256KB ROM, 20KB RAM)</li>
<li>the ADC : the KP3 has a AKM 5381ET, the KaossPro has a AKM 5358AE</li>
<li>the 64Kbit EEPROM : the KP3 has an SPI AKM 93C10AF, the KaossPro has what appears to be an I2C L64 0S33W EEPROM which is unknown to Google</li>
</ul>
<p>The ADCs are probably compatible, and the H8S/2215C CPU (<a href="http://www.renesas.com/req/product_document_lineup_child.do?REGION_KEY=1&LAYER_KEY=111&PDF_URL=http://documentation.renesas.com/doc/products/mpumcu/rej09b0140_2215hm.pdf&TKUPDATE=true&APNOTE=true">the manual can be found here</a>) of the KaossPro should be able to run the KP3 code just fine. However, if they switched from an SPI EEPROM to an I2C one, the KP3 FW will need to be patched...</p>
<p>I do not have the KaossPro schematics to check every connection, so if someone has/finds the Kaossilator Pro Service Manual, please let me know !<br />
I would also gladly appreciate if someone could do the same work on a Kaossilator Pro + or a KP3 +.</p>
<p>That's mainly what I found so far on the hardware side.
<br />
<br /></p>
<h4>Now on the software side</h4>
<p>I looked at both, the KaossPro (V1.02) and the KP3 (v2.00) firmware, and they follow the same format :</p>
<ol>
<li>a 256 byte header</li>
<li>a 256 kbyte (0x40000 bytes) block, which is the actual FW padded with 0xFF (the size of the H8S/2215C On-chip ROM, lucky us <img src="/themes/default/smilies/wink.png" alt=";-)" class="smiley" /> !)</li>
</ol>
<p>I saw no encryption/compression, nor signature.</p>
<p><img src="http://blog.rona.fr/public/KaossilatorPro_V102_HEX.png" alt="KaossilatorPro_V102_HEX.png" style="display:table; margin:0 auto;" title="KaossilatorPro_V102_HEX.png, sept. 2014" />
<br />
<img src="http://blog.rona.fr/public/KP3_V200_HEX.png" alt="KP3_V200_HEX.png" style="display:table; margin:0 auto;" title="KP3_V200_HEX.png, sept. 2014" /></p>
<p>The header format seems to be :</p>
<ol>
<li>the string "KORG SYSTEM FILE" on 16 bytes</li>
<li>the string "KaossilatorPro" or "KaossPad3" (depending on the targeted device), padded with 0x00 on 16 bytes</li>
<li>the string "SYSTEM" padded with 0x00 on 10 bytes</li>
<li>the FW version on 2 bytes (big-endian), read, as far as I know, by the Updater application only</li>
<li>a 4 byte unknown big-endian value (00 01 0E FF for the KaossPro, 78 FF FF FF for the KP3)</li>
<li>16 unkown bytes (00 00 00 00 00 00 04 00 00 00 00 00 00 00 04 00 for both)</li>
<li>a 2 byte unknown value (02 80 for the KaossPro, FF FF for the KP3)</li>
<li>190 bytes being all 0xFF</li>
</ol>
<p>The FW block seems to be exactly what the Updater will write into the ROM. The first 512 bytes match the expected Exception Handling Vector Table, the first vector being the actual entry point address (0x210).<br />
I built <a href="http://www.gnu.org/software/binutils/">the binutils tools</a> for the H8S arch, and used the generated objdump to disassemble the code. The result at 0x210 looks legit as expected, but I did not find enough time to analyze the code yet...<br />
The first bytes of the code section (0x200) are "KORG", followed by what appears to be the version in big-edian, probably the one returned/displayed by the device itself.
<br />
<br /></p>
<h4>What we learned so far</h4>
<p>The KP3 HW is very similar to the KaossPro one, however its firmware won't work as is on it. Some parts (at least the EEPROM access) will probably need to be patched. I say probably because we can see an unpopulated footprint close to the EEPROM that might be a SPI alternative for it.<br />
I still hope that the Kaossilator Pro/Pro + HWs are the same, but since I have no information on it at all, please do not hesitate to share anything you might find.</p>
<p>Regarding the firmware format itself, it seems that the code can be easily modified. However, that looks a little risky considering there is no recovery nor bootloader that would allow to restore a working firmware in case something goes wrong (the code allowing to update the unit seems to be in the firmware)... So for now, I will not play with that !</p>
<p>According to the H8S/2215C manual, it looks like there is a way to boot the CPU from the USB, which would allow to repair a damaged unit, as well as perform some safe tests. I will try to find more information about that !</p>First !urn:md5:334641c005b57e9132c420a0ffc46be82014-01-30T16:11:00+00:002022-04-24T21:37:36+00:00JCGeneral <p>Well, this is my first post on this blog, and I hope others will soon follow...</p>