Project Logs

Collapse

• Dependencies

  Anders Helgesson • 12/01/2024 at 14:00 • 0 comments

  So the greenpak software didn't want to start as I'm missing a newer version of glibc. Slackware 15 is currently running glibc 2.33. I could switch to current which runs 2.40 or just install the glibc package from the current?

  There is probably some other dependencies missing so I checked.

  bash-5.1$ ldd /usr/bin/GPLauncher
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/GPLauncher)
          linux-vdso.so.1 (0x00007fff6a735000)
          libQt6QuickControls2.so.6 => not found
          libQt6WebView.so.6 => not found
          libQt6Sql.so.6 => not found
          libQt6QuickWidgets.so.6 => not found
          libupdaterclient.so.1 => not found
          libcoregp.so.1 => not found
          libsettingsmodule.so.1 => not found
          libgui.so.1 => not found
          libQt6Quick.so.6 => not found
          libQt6Qml.so.6 => not found
          libQt6Widgets.so.6 => not found
          libQt6Gui.so.6 => not found
          libQt6Core.so.6 => not found
          libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007feb22910000)
          libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007feb228f5000)
          libc.so.6 => /lib64/libc.so.6 (0x00007feb22716000)
          libm.so.6 => /lib64/libm.so.6 (0x00007feb225ce000)
          /lib64/ld-linux-x86-64.so.2 (0x00007feb22b5e000)

  QT6... Okay slackware current has QT6, I will install that package and try again. Think there will be missing dependencies for QT6 aswell.

  bash-5.1$ ldd /usr/bin/GPLauncher
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/GPLauncher)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /usr/lib64/libQt6Quick.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.38' not found (required by /usr/lib64/libQt6Quick.so.6)
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib64/libQt6Quick.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6Quick.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /usr/lib64/libQt6Qml.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6Qml.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.38' not found (required by /usr/lib64/libQt6Qml.so.6)
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib64/libQt6Qml.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6Widgets.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /usr/lib64/libQt6Widgets.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.38' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libgcc_s.so.1: version `GCC_12.0.0' not found (required by /usr/lib64/libQt6Gui.so.6)
  /usr/bin/GPLauncher: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib64/libQt6Core.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libgcc_s.so.1: version `GCC_12.0.0' not found (required by /usr/lib64/libQt6Core.so.6)
  /usr/bin/GPLauncher: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /usr/lib64/libQt6Core.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6Core.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by /usr/lib64/libQt6Core.so.6)
  /usr/bin/GPLauncher: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/lib64/libQt6QuickTemplates2.so.6)
  ...

  Read more »

• Pull ups, DTMF, ISR and user interaction

  Anders Helgesson • 11/30/2024 at 21:48 • 0 comments

  When running through some tests in my code the SDA and SCL were low, it seems like stupid me forgot to include the pull up resistors for the MCP2221A, so I added them to the breadboard.

  Stupid me had also made the assumption that I2C worked kinda like CAN between chips but that is not the case so I have to poll the SLG46826V from the MCU to get which key is pressed.

  The now smarter me have decided to use one of the free GPIO's on the pico-lipo to tell if a key is held down by setting the pin from the SLG46826V. Thus when the handset is picked up and instead of constantly polling the SLG46826V on the I2C bus the MCU will check the GPIO pin instead and as soon as it goes high it will communciate with the SLG46826V to get which key is pressed.

  But constantly polling the GPIO pin isn't very efficient either so using an ISR(Interrupt Service Routine) for the pin is better. Then when the device is idling with the handset off it will play the dial tone. The pin goes high and now it get into the ISR and it will poll which key is being held down, plays the DTMF key tone until the pin goes low. When the pin goes low the ISR will send which key was pressed somewhere for processing by the MCU and reset the ISR.

  That left me with some questions.

  How long is the timer before a call is initiated in a DTMF system?

  Apparently it's between 4-6 seconds, emergency numbers are acted upon directly when received.

  How do I manage the countdown timer?

  Probably best to have a state for when dialing have been started and it handles the timer and emergency number dailing. So the ISR checks if it's the first digit entered and switches to this dialing state. The ISR then resets the timer each time a button is pressed or constantly with a key held down.

  What happens in a DTMF system if too many digits entered? Is there a limit to how many digits can be received?

  There is no real limit in the system but the International Telecommuncations Union standard E.164 have specified that 15 digits are allowed which also includes the country code. So I will go with a 15 digit limit in my virtual DTMF system. In a PSTN(Public Switched Telephone Network) numbers beyond the 15th will just be ignored so I'll go for the same. The user can bash the keypad all day but only the first 15 digit are used.

  What happens if a user holds down two keys in a DTMF system?

  It seems to be up to the implementation of the DTMF phone in question. So I guess I will see what I can do in the SLG46826V to prevent it and only register the first key and any other keys pressed keys are ignored.

  Where do I store the digits pressed?

  I can have 2 vectors for these, one local inside the state which keeps track of the digits that have been entered and a global that is set once the timer expires, that can also be used for a recall functionality.

  I've added a dialing state to my code which it will switch to when the first digit is received. Now I have to use the greenpak designer software to make the keymatrix scanning work and ofcourse connect all the hardware together.

  Yesterday one of the feature creeps show up again and he whispered that instead of using a FXMA2012 levelshifter for the framework expansion card you should you use an I2C isolator instead like the ADM3260. Suddenly one of the other feature creeps yelled out "Then you wouldn't be able to interface with a 1.8 volt I2C bus! Get away from him!". They started arguing about it, how QWIIC is 3.3V and the ADM3260 would also be able to interface with 5V so it would be STEMMA compatible. They came to the conclusion that interfacing with a bus that already have a master is the job of another tool like the bus pirate. This tool would be used to test QWIIC and STEMMA stuff. What do you think they asked and looked at me. It's difficult to ignore them but I have to until this project is finished.

• I2C, Greenpak's and feature creeps

  Anders Helgesson • 11/27/2024 at 21:22 • 0 comments

  After the small set back with the bell ringer I decided to work on another part of the project for a bit. Scanning of the keypad matrix. For this I've decided to use a greenpak device, the SLG46826V.

  The SLG46826V is one of the MTP devices (Multiple time programmable) it's NVRAM can be written to 1000 times. This allows you to perform in-circuit updates of the chip if for example a design fault is found.
  

  Here is the block diagram of the device. Image is from the datasheet.

  There are 3 memory spaces, Register, NVRAM and an emulated EEPROM which can be used to store calibration data, settings and other things.
  

  The emulated EEPROM is seperate and acts kinda like a I2C EEPROM and is not usable by the SLG46826V alone but it could remove the need for an EEPROM on your board. It does however have the same 2Kbits of memory with 1000 times writable as the NVRAM. It features write protect for all or certain parts of the emulated EEPROM memory space which can be made permanent read only if you want.

  You can change register settings while the device is operating which means that you can alter settings using a MCU for example. This allows you to do many cool things. Which is why I got interested in greenpaks when I first discovered their existance. If you are interested check out their GreenPak cookbook.

  The 10 year counter example in the cookbook is a bit scary and hopefully will not be used to make designs that will brick the device shortly after the warranty ends. Skeptical me comes out sometimes. Hopefully that type of design only used for counting when a AED battery or something like that should be changed.

  Anyways...

  The offical debug tool for the SLG46826V isn't very cheap so I decided to not get it. The SLG46826V like other greenpaks are setup through I2C. First I thought about using my Beagle bone black as an interface for it. Then I found the MCP2221A which is interesting so I ordered one. After I ordered the device I looked at the offical tool from renesas and it also uses a MCP2221A. Although the renesas debug tool have all the protection you'd want, there is probably a joke to be made here but I'll refrain this time. I can still use their software to make the design for the SLG46826V and then extract the data needed to program it through any I2C interface. However it introduces another step but it also offers more learning opportunities. Why take the easy road when the hard road looks more fun.

  I wired my design together on a breadboard but I didn't have a capacitor needed to use USB bus power to power the device. So I decided to use a 3.3V LDO to power it instead. It does remove the need for the levelshifter but I will use it anyway.
  At first the circuit didn't work because stupid me put the 3.3V LDO backwards which was easily fixed and it works like a charm.

  Here it is my creation.

  USB-C module splits out BUS voltage, GND and the signals D+ and D-.

  The 3.3V LDO(NJW418U3) powered from the bus powers the MCP2221A and the first LED from the left tells that the device is powered.

  Second LED from the left tells if the USB connection is configuring, it turns off when the configuration is complete.

  The LED furthest to the right tells if there is communcation on the I2C bus, it's on when the bus is idle, it turns off when communcation is happening on the bus. 

  The I2C connection goes through a FXMA2102 for level shifting but not really neccessary in my case, it was going to be used to level shift the I2C to 3.3V if the MCP2221A was bus powered.

  I made a cable for it by using cables ripped off from a rainbow ribbon cable and with a tiny screwdriver I removed the QI pins from the housing and put them into a 4pin housing instead. This makes it easy to plug into the SLG46826V module.

  While working with the MCP2221A and SLG4682V alot of feature creeps showed up, they talked all about why not make an awesome commandline tool for the MCP2221A and while your at it make your own cool GUI...

  Read more »

• Measuring the H-Bridge output

  Anders Helgesson • 11/24/2024 at 21:24 • 0 comments

  I reconnected everything up and used the oscillscope to measure the signal coming out of the H-Bridge.

  The measured output looks a lot like a square wave to me. Which means that the motor driver filters out noise and my SPWM signal is considered noise.
  I measured it again using two 4.7k resistors in series as a load. Same thing.

  Well I guess I learn new things everyday. This time I guess I really should have read the datasheet properly and understood the device.
  Back to the drawing board for the h-bridge design. :)

• Programming

  Anders Helgesson • 11/24/2024 at 08:10 • 0 comments

  I've been going through the programming for the project and decided to use a finite state machine which controls the behaviour of the telephone. It looks like this. It's pretty straight forward how it should work.

  I've implemented the state machine and it runs fine. I might need to add some transition states if it simplifies the code. I can add features to the states as I connect components to the breadboard and progress on the project.

  I've added a toggle switch to simulate the handset and an other push switch to simulate the URC from the modem. This will make it possible for me to start programming the sleep and wakeup functionality without the modem.

• Bells

  Anders Helgesson • 11/13/2024 at 20:15 • 0 comments

  I had some time the other day to work on my project so I connected the oscillscope and checked the time between the channels when it turns off and then on.

  I will never run the h-bridge over 50hz but even if I run it as quickly as I can with my 20kHz pwm output, just one LUT element of deadtime is enough since the h-bridge can handle up 400kHz. My deadtime is in the microsecond range and the h-bridge do stuff in the nanosecond range. So I should be safe to connect the h-bridge.
  

  I've desoldered the connections to the old h-bridge from the PSU and added input and output capacitors which will hopefully give me lower coldstart times. I also soldered the pin header on the h-bridge. I also soldered the socket header on my uart module which I'm going to use for another project for a bit.

  Now I just have to make sure we don't get any back emf from the coil back to the h-bridge as our 40 volts is very close to the maximum voltage of the h-bridge which is 44 volts.

  I removed the old capacitor from the bell ringer replaced it with a new one, added resistors to protect from back emf.

  As I read through the h-bridge IC datasheet I notice that it seems to put in a deadtime of 200-300ns in hardware, which I missed.
  It was written more like a note instead of on the specifications page, which is why I missed it so many times looking through the datasheet.

  I connected everything together. Turned it on and the bells rang nicely. I read the voltage coming out of the H-bridge IC it was at 44 volts which is the H-bridge maximum. I have to take readings with the oscillscope to see whats going on.
  

  The fact that this motor driver can be used have reduced the size of the h-bridge to a small IC chip.
  

• DMA and AI

  Anders Helgesson • 10/27/2024 at 20:25 • 0 comments

  After trying to get the SPWM working on the pico LiPo for quite some time I finally managed to make it work. I have to check the output with an oscillscope to make sure I have enough deadtime. I couldn't get the internal DMA pacing timer to work so, I used another pwm slice as timer for now. If I need to I might use PIO for timing. Still have to make measurements and do live testing to see if it's good enough.

  Using AI has been from very useful to not so much to downright misleading. Mixing API's, assume microcontroller functionality and so on. I looked through the documentation, the API's for the libraries used and manged to get it to work. Although the AI led me on a wild goose chase it was helpful in most cases but not so much for writing functional code at least in rust.

  Like one big CEO said that one shouldn't learn programming as AI's can do that. Well we are not there yet I think. With current AI technology they are trained and do not reflect or correct their training on their own, they still go by equation of "shit in = shit out". Perhaps mere mortals don't have access to these super programming AI's but then where are those bug free drivers?

• LUT, PIO and SPWM

  Anders Helgesson • 10/13/2024 at 21:40 • 0 comments

  I've been looking at how I should set up the SPWM there are some options but using a PWM slice should suffice. A LUT will store the sinewave data, I'm thinking of using 1024 samples at 32 bits which holds 180 degress of the sinewave for both pwm slices. Using 16 bits for each channel. 

  Since the LUT begins with both channels at 0 and both channels are 0 in the middle and at the end. We should have enough deadtime to not cause shoot through. It depends on how fast we feed the PWM slice with data. I have to check to make sure that it's enough.

  DMA will be used to feed data to the PWM peripheral so we can free up the cpu for other tasks. 

• ADC troubles

  Anders Helgesson • 10/10/2024 at 22:37 • 0 comments

  This morning I worked on reading the ADC so we can get the battery voltage. I'm pretty sure I'm missing something beacuse I always got similar results even when plugging in the USB which starts charging the LiPo. I have to look at the schematic and see how the voltage divider works. I'll think I'll leave this for now until it becomes relevant during the power supply part of the project. On to other things.

• Dual-tone multi-frequency tones

  Anders Helgesson • 10/08/2024 at 04:34 • 0 comments

  Something occured to me that to get the experience of a old phone I need to feed DTMF tones into the AUX of the Codec. This could also be used to get the dialtone.

  I'm thinking of feeding a DAC from LUTs for each tone or superimposed tones, an op-amp adjust it to line-level before feeding it into the codec. I've also read about using PWM to output audio and perhaps with a good filter it can make clean sinewave tones.

  This adds more complexity and more things to learn. :)

  Then I could change the setting in the codec, if I want to get the tone out to the Modem so the person on the other end also can hear the DTMF tones.

  I guess this part will be more relevant after I get the keypad matrix scanning working.

View all 24 project logs