Category: Zhejia’s Status Reports

This week I worked on the testing and verification of our design and use case requirements, as well as ensuring that my software was able to reprogram the keys successfully. Since last week I developed the communication protocol, this week was focused on the testing of the protocol to ensure that it was reliable and consistent, and could assign all values to all keys without issue. I began by specifying a set of values which each key could take. Next, I generated a few random keymaps to program onto the keys, testing that a mixture of possible key assignments would work without issue on the keyboard. I then tested the functionality of the key to receive duplicate values by programming all 16 keys with the same functionality. I also tested modifier keys such as shift and control, which had a few issues, especially with control having different values for Windows and Mac. However, as there isn’t really a good way to easily detect the system that the keyboard is connected to and have it reprogram itself on the fly, I opted instead to simply document the abnormality for the user to take care of. While this isn’t a perfect solution, because of the time constraints, I was unable to develop a better approach. During the week, I also helped with additional testing, using the keys to assist in my editing of the video final project for another class, which did not end up raising any issues.

I believe I am on schedule, and there is nothing really planned left other than more rigourous testing and the final deliverables.

Next week I plan on finishing the final deliverables for this class, including the report and poster.

This week I worked on the software programmer, the testing/validation, and the slides for the final presentation. For the software, I sketched up and implemented the UART transport protocol to program the keys. The interface first sends a bracket, followed by a comma separated list of key assignments, followed by a closing bracket. I also devised special codes such as RAISE for layer and other modifier keys. I then programmed the software to be able to send this set of assignments to the receiver microcontroller over UART. On the pure software side, I updated the application code to allow the dynamic resizing of the window, as well as the ability for it to remember where each key is after a resize. Next, I worked on the testing and verification of the various requirements. I first tested the wireless charging capabilities by connecting an ammeter in series with the wireless charging module and then measuring the current received by the battery. Next, I tested the latency of the overall system by connecting all the keys and recording them being pressed using the slow motion option on Ben’s phone. The latency was measured from the instance the key was pressed down to the bottom to the time the letter took to show up on the screen of the connected computer. Through this measurement I found that the typical latency is no more than 9 frames in total. Next, I tested the power consumption of the switch assembly by connecting an ammeter in series with a power supply set to provide 3.7v to the battery input of the Seeed XIAO board. Through this method, I found that the keys drew around 6.5mA when active and 0.7mA when sleeping. With this series of tests finished, I updated the final presentation to reflect these changes. Finally, I tested the ultimate range of the BLE receiver by taking a key as far as possible without losing connection. Ultimately, I was able to take the key around 45 feet back before running out of space indoors. However, the key was still connected despite this.

I am slightly behind on the software, as I was supposed to test the integration of the software and hardware components this week, but unfortunately I did not have time to verify. However, since the protocol should be the same, I do believe that there should be minimal issues. I will catch up by performing this test and then fixing any issues that arise before the presentation next week.

Next week I plan on working on the final report and the poster, as well as ensuring that the keys work correctly under a variety of conditions.

This week, I first worked with Korene to try to decipher what exactly the equivalent circuits for the 2 chips on the wireless transmitter are and we tried to solder wires from the resistors and capacitors on the board so we could connect it to a breadboard and easily swap them out, but one of the resistor positionings was quite awkward, so on both attempts, we ended up ripping the pad off of the board, rending the boards unusable. (We made 1 more attempt after the first on failed). We also did some testing on the connection between the 2 chips and discovered that the first chip, the oscillator, was not the one causing the shorting issue since it still operated fine (outputted a consistent square wave) even when we switched out the inductors or completely removed them, which means the issue is likely with the T5336, which is the one completely lacking documentation but it is likely a power MOSFET, so maybe the issues have to do with it’s operating point?

After some setbacks there, I worked more on the keyboard configuration software and implemented freely moving keys, so now the keys can be moved by the user to any location within a rectangular “baseplate” and still function properly.

Additionally, I also implemented the save functionality and it now saves the key binds and the positions of the keys to a file so they can be kept for next time. The idea is also to interface this with bens code and only upload a text file to the USB device rather than reflashing the entire board to change just the key binds.

Lastly, I started adding the components to make the user be able to configure different key binds on to different layers. (Typically, personal keyboards allows you to set a key to toggle layers, which changes all the key binds on the keyboard depending on the current layer).

I will be testing the visible wobble of the keys. I will be doing this by recording the typing with a video camera and seeing how much the keys deviate from a central baseline. Additionally, I will be measuring the charging time and rate. Charging time will be measured using a timer and a battery level readout from the keys. Charging rate will be measured using a ammeter connected to the battery charging circuitry. I will also be measuring the costs associated with each key. This will be done by looking at the spreadsheet and figuring out an amortized cost per key for the keyboard.

I am slightly behind schedule for the wireless charging due to the issues with identifying the chips and how they function with the lack of documentation. I am on schedule with the UI create. We plan to discuss with Prof. Tamal tomorrow (Sunday) about issue with the chips.

Next week, I plan to implement most of the functionality of the UI and start interfacing with the microcontroller if there is time. I also plan on making progress and figuring out the situation with the wireless chips, but that progress depends on our discussion with Prof. Tamal.

This week I worked on the wireless charging system with Korene. We started out by trying to find out the resonant frequency, but the frequency we read on the oscilloscope was not the resonant frequency of the capacitor and inductor. Specifically, we measured 65kHz for the frequency, and 22uF for the capacitor and 30uH for the inductor, which do not match our resonant frequency. Regardless, we first tried to replace the coil and the capacitor with the resonance coil and capacitor, which worked fine for the receiver, but for the transmitter, when we replaced it, we set the power supply between 9v and 12v at a current limit of 500mA and it would always max the current limit without reaching the required voltage. Additionally, one of the chips would get really hot, indicating that the current was shorting through the coil. After various experiments, we found that for this board, you must both have within 5uH of 30uH and a low enough resistance in order for the transmitter board to not max out on the current draw from the power supply. We tried various things including chaining 4 small inductors together to create a 30uH inductor to test if the inductance alone was the issue, but that did not work since the small inductors have more resistance than the original coil, and the higher the resistance, the more current it would draw from the power supply. Additionally, we looked at various example circuits on the datasheet, and the capacitor that the inductor is supposed to be in resonance with does not change value, remaining constant at 47uF across all the example circuits, which is quite confusing. After discovering that it would impossible to tune either the capacitor or inductor alone to get the transmitter board to work, since the inductor needed to be both lower resistance and higher inductance (thus preventing us from putting multiple coils in series or parallel for them to work), we moved on to trying to understand the resistors on the board and the different pins on the transmitter chip, which can be seen in the datasheet. The thing about these resistors in the example circuits is that there are multiple circuits with the same inductance and capacitance, but slightly different resistor values, due to the difference coil sizes, which I hypothesize has something to due with the extra coil caused by the larger coil size. However, the datasheet only labels each of the pins and we have no idea how the pins work or how they calculate the output frequency. Additionally, there is one circuit in the datasheet (the last one) that almost exactly matches the configuration on our transmitter board, except for the capacitor value, which we eventually changed to match the circuit. The resistors were all the same, except that circuit was configured for 3.7uH coil transmitters, while the current circuit only worked at around 30uH.   this circuit was exactly the same as the one on the board, but when tried to put two of our coils in parallel and attach it, which would give us a 4uH lower resistance coil, the board still did not work and we measured the output through the oscilloscope, and it looked exceedingly strange, and non sine-like.There is a lack of documentation on the functions of the XKT-412 pins and there is no documentation on the XKT-335 which I believe is a power MOSFET. 

I met a roadblock due to the documentation of the chips. As a remedy, I intend to discuss this with the TAs and the professor as to a remedy for this. Additionally, since the receiver board works, I have placed an order for a transmitter board with smaller coils in the hope that it would allow us to sidestep the troubleshooting of the transmitters entirely.

Next week I hope to work on the software and implement more functions. Additionally, I hope to proceed on the magnetic charging with the new transmitter boards. 

 

This week, I first worked on modifying the evaluation boards that arrived from amazon with Korene, desoldering the inductors from a pair of them and measuring the inductance by scraping off the inductive coating and using an LCR meter. Additionally, we also characterized the oscillation frequency the transmitter board was at (around 64kHz). We also tried to follow the traces and figure out which capacitors and resistors were contributing to what, which we mostly figured out, and then we tried to measure the relevant onboard capacitors with the LCR meter to find the ideal resonance frequency, but the calculations ended up way off from the actual operating frequency of 64kHz, so more investigation next week is necessary.

Next, I worked on updating the keyboard driver code on the main microcontroller to accommodate features including:

• modifier keys (keys that are not visible letters like Ctrl and Shift)
• multiple key presses at the same time
• long key presses typing multiple letters (like aaaaaaaa for holding down ‘a’)
• preliminary different layer support (different ‘layers’ have different keybinds)

Lastly, I started work on a basic GUI for the keyboard configuration software using pyqt6. I ran into some problems with my python installation location and had to spend some time finding where different versions of python were installed in my windows system and editing my path until the installed pyqt6 could be used (I was missing a python3.dll file). After that I created this preliminary GUI:

It functions as you would expect: Configurate configures the keyboard shortcuts typed into the keys (by generating an arduino code file), and to differentiate between the keys, when you click a physical key, the corresponding digital key changes color/lights up. Additionally, I plan to have the keys be draggable to different locations in the UI for users to mimic their current layout if they would like.
However, most of these functionalities are not yet implemented.

I am on schedule.

Next week, I hope to work with Korene to get a pair of evaluation boards to work with our small inductors. This will likely take a long time. If I have more time, I will finish implementing essential features for the configuration GUI.

This week I worked on creating a prototype for the keyboard firmware that acts as an interface between the key receiver and the computer. I prototyped this on the Arduino Nano 33 IoT, since the Arduino Keyboard library was not compatible with the Seeed Xiao boards. However, this caused a few issues since to get the keyboard working, a new driver was needed for the Nano 33 IoT. Additionally, I had to make sure the right version of the Keyboard and USB libraries were installed, as there were some issues posted online with the keyboard device not being recognized in certain versions. Finally, I modified the KeyReceiver code to be able to distinguish between the individual key presses and send a different character as a keyboard depending on which key was pressed.

I am on schedule this week since I was scheduled to work on the keyboard programming software, and having the Arduino being able to act as a keyboard was an important first step to this.

Next week, I hope to finish the code template that the keyboard customization software will edit and flash to the main board.

This week, I worked on the interface between the magnetic charging and the seeed xiao BLE board. I researched the schematic diagrams and tested which pins can be used to charge the LIPO battery through the seeed board. We don’t want to directly charge the LIPO since the seeed board has a battery management system (BMS) already (BQ25100) which guarantees safe charging since overcharging LIPO batteries is dangerous. Looking through this schematic diagram, which is for the sense version of the board, but is the same ignoring the sense components, I found that charging is done though V_BUS, which is connected to the BMS, so the next step was trying to find an external pin that connected to V_BUS.  The pinout sheet given on the official website had it labeled as AD2 instead, so I spent some time trying to find which external pin was AD2 to no avail. Later, after examining the schematic again, I realized that this pinout sheet was for the nrf52840 chip instead of the seeed board. Although none of the pinout diagrams for the board officially labelled a pin as V_BUS, I presumed V_USB was likely connected to V_BUS since the USB was connected to V_BUS in the schematic. Then I used my power supply to provide 5V to the V_USB pin (pictures on the team status report), and at first it did not work, so I thought that V_USB might be connected to V_IN instead of V_USB, which would be an issue, but actually, the issue was connecting the ground pin to the ground terminal of the power supply did not work and it instead needed to be connected to the negative terminal of the power supply. In the end, I successfully charged the LIPO with 3.25V-5.5V although the 3.25V only provided 8mA of current while it basically gets full current of 60mA at 4.35V which matches the recommended operating conditions of V_USB in the datasheet. According to the datasheet, we also should be able to charge with low voltages using the VDD pin, but I have not tested that.

Of course, I worked on the design report as well.

My progress is on schedule, and I plan to research and start writing the keyboard driver software to send keypress data to the computer next week.

This week, Korene and I worked on finding ways to improve the power delivery of the magnetic charging system since from last week, we discovered that a simple circuit would not deliver enough current to charge the seeed xiao board. We first spent some time trying to look for power amplifiers that would work at the high AC frequencies that we would be amplifying as well as a voltage-controlled sine wave oscillators, which were a bit elusive, and a lot of circuit diagrams came up instead. Many of the ICs that came up turned out to generate non-sine waves (many trapezoidal looking waves – basically square waves with rise and fall times) and figuring out which waveform the VCO outputted was often not on the datasheet. After talking a bit with Professor Tamal about using an ecosystem, we switched direction to looking into Qi wireless charging compliant ICs and boards, where we found a couple small sized wireless charging kits (Wireless Charging 10mm Coil 150mA Wireless Transmitter + Receiver Power Charger 5V Output (10mm Coil 150mA) (amazon.com)) on amazon and zoomed in on the product pictures to get the board name/chip name – XKT-412. This chip’s datasheet was only in Chinese and could only be found on AliExpress and Amazon. After some attempts at deciphering it, we moved on to trying to find Wireless Charging ICs on digikey. From there, we found some good ICs on digikey that came with an example project but those chips were obsolete and could no longer be bought. Then, we went over our seeed board’s battery management system requirements and ordered wireless charging transmitters by current, and many of them had quite low (3-3.6V) voltages, which we thought was too low at the time, and the ones with higher voltages either had tiny currents, no listed current, or were obsolete and were not sold anymore. We then looked on mouser and looked through many viable options, and unfortunately, many of them were not stocked (BD570xx Qi / PMA Wireless Power ICs – ROHM | Mouser). We eventually found a chip that had 4.5-24V along with 87mA current that was stocked, but that chip had 68 pins and was very complex and the datasheet did not give us a lot of information on how to use it or how the many pins worked. This was when we reached out on slack for help and moved to looking at the application notes instead. We then had a meeting with our instructors about this, and tried to look for more simple ICs since that IC had many components we do not need, and in the end we circled back to the amazon wireless charging kits, and found another variant of the XKT series, the XKT-510, which actually had a datasheet in English, although not with perfect translations (XKT-510.pdf (sakura.ne.jp)) along with example wiring circuits of both the transmitter and receiver to go along with it, and we decided that ideally, we would go with these chips as their pinouts and circuits were much more manageable than the 40-68 pin wireless charging ICs we found on digikey and mouser.

Our progress is slightly behind as although I hoped to resolve the power and current issues by this week, the extensive amount of research we had to do as well as the shipping time for the XKT ICs will push the power integration and PCB manufacturing on Korene’s part further back than we anticipated. With this adjustment in schedule, in the meantime, I can find the resonance for the official coils we ordered as well as start working on my other task, the design of the keyboard configuration software instead and shift around my schedule a bit.

Next week, I hope to record the required capacitor values for resonance for the industrially made coils we ordered, which should arrive soon (?) and work on the design and plan for the software configurations that will go on the main microcontroller, which for now is just another seeed xiao board. We should also order samples to test the XKT chips as soon as possible due to their weeklong shipping times.

This week Korene and I troubleshooted our resonance issues from last week and found that the signal generators in the 220 Lab increased in voltage as the frequency increased, leading to being unable to spot the peak amplitude on the oscilloscope (the math->division menu item was also quite noisy). However, we moved to using the ADALM’s spectrum analyzer and found the resonance with no problem after setting that up.

After that, we also constructed the rectifier/receiver and transmitter circuits on breadboards and got it to output ~6V, which is the lowest charging voltage the Seeed Xiao microcontroller’s battery management system can take, but at too low of a current.

These are skills we learned in 18-220 and 18-100.

Here are some pictures and diagrams of our constructed circuits:

I also worked on the design PowerPoint slides with everyone else.

My progress is on schedule, and next week, I plan to try to increase the current delivered and try attaching the battery to microcontroller to a breadboarded circuit and get the microcontroller charging.

I worked on the inductive charger, first making my own coil, then trying on some coils I acquired for more testing. I first calculated that the resonant frequency would be around 24 kHz, with the inductance of 43 microhenries in series with a capacitor of 1 microfarads. However, experimentally, I found that the real resonant frequency was very difficult to measure accurately as simply switching the direction of the probes would change the frequency at which I measured the highest output voltage for a given 5v input. Eventually, I settled on a ~41kHz resonant frequency for the inductor, which gave me an output voltage of ~3.4v (with a 5v input), which is close to the charging voltage for our planned small LIPO batteries, but I believe more investigation is required for the strange resonant measurement behavior.

We are mostly on schedule, having ordered/acquired the experimental parts needed, but the strange resonant behavior did put us a little behind schedule for proof of concept, which I will work on more with Korene next week to resolve. Asking staff may be an option as well.

In the next week, we will finish the proof of concept and create the circuit that integrates and stabilizes the magnetic charging for integration with the boards *when* they get here. (To be clear, the boards will likely not get here next week).