• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Control of BBB-based audio appliances

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Member
Joined 2007
Paid Member
Please explain, how you poweroff or shutdown your Beaglebone black by smartphone (android)? I use DEBIAN OS and MPDROID, M.A.L.P applications etc
Should I write and activate scripts on the BBB?

To shut down the BBB from the command line, one need only execute 'shutdown' as root. If that is the only objective for android control, then the simplest solution is an android SSH client. I use iOS and not Android, so I can only suggest that you choose the Android SSH client that works best for you. It seems from online reviews that 'Juice' and 'Far Commander' might be suitable.

If you have more objectives than merely shutting down, then you may wish to explore other methods of control. I have been pleased with methods that use a local Python program on the BBB and communicate from mobile devices via text through TCP or UDP. I use NetIO, which has both iOS and Android interfaces to a Python effector program running on the BBB. Describing that was the initial purpose of this thread, if you wish to read previous discussion here. Other options are available as well. If you search GooglePlay for 'remote control tcp/udp', the list will be overwhelming but you can get started learning a system with broader capabilities and convenience than a SSH client on the phone.

How do I turn off my BBB at the moment? Its ugly but it works as part of a control system for multiple audio components - I have a RPi controlling switched power outlets, and I just cut the power. :) The botic kernel and BBB battery is then activated for an orderly shutdown of that part of the system. I am planning a better way to do it using a relay on the Hermes power interface but I haven't taken the time yet to implement it.

...hope that gives you some ideas on the best way for you to proceed...

Frank
 
To shut down the BBB from the command line, one need only execute 'shutdown' as root. If that is the only objective for android control, then the simplest solution is an android SSH client. I use iOS and not Android, so I can only suggest that you choose the Android SSH client that works best for you. It seems from online reviews that 'Juice' and 'Far Commander' might be suitable.

If you have more objectives than merely shutting down, then you may wish to explore other methods of control. I have been pleased with methods that use a local Python program on the BBB and communicate from mobile devices via text through TCP or UDP. I use NetIO, which has both iOS and Android interfaces to a Python effector program running on the BBB. Describing that was the initial purpose of this thread, if you wish to read previous discussion here. Other options are available as well. If you search GooglePlay for 'remote control tcp/udp', the list will be overwhelming but you can get started learning a system with broader capabilities and convenience than a SSH client on the phone.

How do I turn off my BBB at the moment? Its ugly but it works as part of a control system for multiple audio components - I have a RPi controlling switched power outlets, and I just cut the power. :) The botic kernel and BBB battery is then activated for an orderly shutdown of that part of the system. I am planning a better way to do it using a relay on the Hermes power interface but I haven't taken the time yet to implement it.

...hope that gives you some ideas on the best way for you to proceed...

Frank
I turn off my BBB at the moment by button in Volumio menu.
 
Member
Joined 2007
Paid Member
Update to BBB control software

Hi Friends,

A while back in this thread I was having problems with I2C controlling the (then new-to-me) ES9028/38. This is a happy update to share some of my success and the methods that worked for me.

Review:
1) Sometimes various registers on the DAC chip would change in response to disturbances in power - either static discharges or surges from other appliances on the same house circuit.
2) Spontaneous mis-configuration of the ES9028/38 output could bump signal volume to 100%, or sometimes unbalance output causing DC through the balanced amps. ...rather bad for voice coils...

Methods tried:
1) Filtering line noise into the DAC. This definitely removed some sources of disturbance to the DAC registers. I isolated the DAC from the rest of the power line using a Furman AC-215A power conditioner. (image below). [I also filtered line current into the amps with a less aggressive solution but it didn't help.]
2) Bypassing power switches on all the sound equipment. Even isolated, the DAC could change configuration based on simple static discharges from being touched in dry weather. Also when powering other sound equipment on/off, there was a chance of unpredictable behavior. I added 3 inexpensive logic-controlled power outlets and haven't had a single 'surprise' since. (outlet image below)

Wireless control of system power:
I decided not to run the BBB/Hermes/Cronus 24/7 because that meant changing too much of an otherwise good power chain. Instead I added a second single board computer to run full-time as a controller for power outlets and server for an 8T media disk. An Odroid N2 worked great for about a year until its networking chip died. I recently replaced it with a less-costly RPi 3B+. The RPi is perfectly adequate although required changes in the python code from what worked with the Odroid N2.

The Python code:
With the changes made for the RPi, I finally removed the last couple bugs from the code. Fresh versions are now available on my GirHub page. 'netio_server.py' runs on the BBB, while 'System_server.py' runs on the RPi. I realize that few DIYers, if any, would duplicate my hardware. The reason for putting the code up is to help any other non-programmers (like myself) with working solutions that could apply to their unique projects. For example;
a) wireless control of outlets doesn't require any custom interface because these products operate with the minuscule current from RPi GPIO pins - they are plug-and-play and the control code examples are straightforward;
b) the RPi and the BBB communicate during startup/shutdown to make the process safe and orderly - especially relative to amplifier power up/down;
c) both the BBB and the RPi wireless controls are on the same control screen on my remote devices - convenient and easy to use;
d) the BBB python code now includes a proper log, and it uses multi-process threads to run efficiently and smoothly;
e) I've found that the best way to compare SQ of different DAC configurations is to change them on-the-fly with controller buttons - examples are in the code.

So, if any of those features would help you, the most recent python code on GitHub can get you going. Again, you don't need a wifi control appliance (phone or tablet) programmed to use the servers - though ultimately they would be ideal. To start, you can trigger the routines by sending a simple text command from any terminal within your LAN.

Comment: The last bug that I just solved was commanding the BBB to shutdown by itself, without just killing the power and letting battery protection take over. It meant going back to an older, less sophisticated command. Any suggestions on how to configure the python environment to use the newer 'subprocess.call' will be appreciated.

Conclusion: IMHO, the success of streaming music services is based on the *convenience* they provide - quality has been an afterthought. In our DIY systems, quality comes first. Improving the convenience of our DIY systems is a matter of personal preference, but certainly *not a frivolous pursuit*. :)

Frank

P.S. Many thanks to Russ, whose help was invaluable when diagnosing DAC instability. Back when everything was unpredictable, the best thing I did was change to 'throw-away' mids and tweeters until problems were solved. Photo below shows what would happen to cheap AMT tweeters when system shutdown went awry, and amp caps from one rail emptied into them. Now all is well, the good drivers are back (and better than ever) and the system is amazingly transparent! :D
 

Attachments

  • Screen Shot 2020-02-20 at 7.54.25 AM.png
    Screen Shot 2020-02-20 at 7.54.25 AM.png
    478 KB · Views: 220
  • Screen Shot 2020-02-20 at 3.02.56 PM.png
    Screen Shot 2020-02-20 at 3.02.56 PM.png
    521.7 KB · Views: 232
  • IMG_0817.jpg
    IMG_0817.jpg
    369.3 KB · Views: 225
Last edited:
Hi,
I would like to ask if it would be possible to add some code to BBB to facilitate BBB (with LiPo battery attached) to shutdown linux in the event of power loss.
The appropriate patch for PMIC tps65217 chip (soldered on BBB) was prepared by miero:
linux-dev/0013-pm-shutdown-on-power-button-press-or-power-loss.patch at botic7-v48 * miero/linux-dev * GitHub

However something was changed in the last tps65217 driver and this patch is no longer valid. (patching gives errors).
So I thought maybe phyton script can be applied instead?

I found some examples addressing similar issuee:
beaglebone_snippets/power at master * pehrtree/beaglebone_snippets * GitHub
but they have 8 year old and I don't know if they still work.

It would be nice to have old functionality (just like the miero's patch):
the linux on BBB with battery can be hardware poweroff after press onboard on/off button or automatically after disconnecting power plug.
What do you think?

There ware also another patch:
linux-dev/0012-tps65217-force-low-noise-fixed-frequency.patch at botic7-v48 * miero/linux-dev * GitHub
I don't know what it does and whether is needed.
Regards,
 
Member
Joined 2007
Paid Member
Greetings Bern, I hope you all is well with you!
I would like to ask if it would be possible to add some code to BBB to facilitate BBB (with LiPo battery attached) to shutdown linux in the event of power loss.
I have not really followed along with efforts to update BBB systems to the latest Debian. I am still using version 8 (Jessie) with full function of the original kernel.

However, I think it is very important to manage the BBB power situation with TPA Hermes in operation. A few lines of Python can certainly do this, at the expense of another running process. As for repairing a kernel patch, that is beyond my level of expertise - when I read C/C++, it might as well be Sanskrit. :D My only reason to use Linux at all is to enable beautiful music in my life!

I see that the status of the power management chip in my BBB is 0x88, which means binary bits 3 and 7 are set to 1. Bit 3 means normal system power is present. If bit two is set then it means USB power is present. If neither, then battery power is being used. If that is the case, then we need to respond before the battery fails. What would you like that response to be? Immediate shutdown, like the kernel patch normally does, or perhaps start a countdown while hoping for power restoration?

I should add that I would rather not do testing on any simple code that we might write for your purposes. I am quite occupied with another programming chore and would have to modify my working system to verify the operation. But I'm happy to help you implement a solution...
 
Last edited:
Greetings Bern, I hope you all is well with you!

I have not really followed along with efforts to update BBB systems to the latest Debian. I am still using version 8 (Jessie) with full function of the original kernel.

However, I think it is very important to manage the BBB power situation with TPA Hermes in operation. A few lines of Python can certainly do this, at the expense of another running process. As for repairing a kernel patch, that is beyond my level of expertise - when I read C/C++, it might as well be Sanskrit. :D My only reason to use Linux at all is to enable beautiful music in my life!

I see that the status of the power management chip in my BBB is 0x88, which means binary bits 3 and 7 are set to 1. Bit 3 means normal system power is present. If bit two is set then it means USB power is present. If neither, then battery power is being used. If that is the case, then we need to respond before the battery fails. What would you like that response to be? Immediate shutdown, like the kernel patch normally does, or perhaps start a countdown while hoping for power restoration?

I should add that I would rather not do testing on any simple code that we might write for your purposes. I am quite occupied with another programming chore and would have to modify my working system to verify the operation. But I'm happy to help you implement a solution...

Thank you. I'm fine and hope that the epidemic doesn't bother you much. Due to the global situation, I have more time for my audio hobby. As far as Linux is concerned, my knowledge is still limited. Although I've learned a bit in recent years, starting from scratch. I use it in two areas: audio and home networking router / firewal wifi ap / NAS.
Recently I installed Debian buster and build RT kernel with botic patches (thanks to coroner21). And the sound from my old Hermes/Cronus with MPD as satellite of my home music server is goooood:). One thing I miss in my new build kernel is just lack of nice, automatic poweroff after power loss when battery is attached.
I think that paweroff behavior could be user defined. We could use delay parameter. For example 0s delay means immediately start the shutdown procedure.

Ofcourse I can test the script in my system.
You are very kind as always. Thank you for your openness and willingness to help.
Regards,
 
Member
Joined 2007
Paid Member
OK, Bern... I think I have something for you. I tried to make a simple script of only a few lines but querying the TI power management chip requires a feature that is not built into the Python I2C tools. I couldn't execute it in only a few lines, though the script 'powerstatus.py' on GitHub from @pehrtree executes the query using a more elegant structure. I was able to make a few changes to that code and (hopefully) do exactly what you want. But again, you are the one who must test.

First, I suggest you simply copy the 'powerstatus.py' script and test that it works on your BBB/system. I expect no problem, and if it works (prints power chip information), then make some simple mods:

1. Add these lines just above the other import statement on line 5
Code:
import time
from os import system

2. Scroll near the bottom and delete these print commands.
Code:
 print "Querying Beaglebone Black Power Management IC on i2c-%s device 0x%x"%(I2C_DEVICE, CHIP_ADDRESS)

    print "On battery power only? %d\r\n"%onBattery()
    print "Charging Battery? %d\r\n"%charging()

    show_reg(STATUS,"STATUS",STATUS_LABELS)

    show_reg(CHGCONFIG0,"CHARGER",CHG0_LABELS)

    show_reg(PGOOD,"PGOOD",PGOOD_LABELS)
3. In place of the print commands add
Code:
    while True:
        if onBattery():
            system("shutdown -h now")
        else:
            print 'beep'
            time.sleep(2)

Note that the indents on the third step are important - everything must be correctly indented. I suggest 3 or 4 spaces per unit (do not use tabs!). First line = 1 unit. Second line = 2 units. Third line = 3 units. Fourth line = 2 units. Fifth and sixth lines = 3 units.

Then run the script ('python powerstatus.py'). Every two seconds it should print 'beep', waiting for you to unplug your BBB and rely on battery backup. Within two seconds of that event, it should execute a self shutdown that will take about 5 seconds to complete. If it works, then the pieces are in place for fine-tuning.

Let me know...

Frank
 
Member
Joined 2007
Paid Member
I should add: you can terminate the program from the command line using the usual Ctl C.

I'm happy to learn that your home music is sounding great! I'm working on a project to extend more music around my house using Raspberry Pis, plus adding a new DAC into the mix. The new DAC will have a custom made isolation interface plus many other custom bits in the form of small circuit boards. They are coming from China right now. I had to learn all of the process from zero, and it has made me appreciate the work of Russ and Bryan at TPA. It is VERY demanding in detail! :D
 
Last edited:
Thanks Frank,
Testing your script I encounter issue that blocks the effective shutdown of BBB after transition from lets say USB power to battery power.
Until I solve it, I can't go on.

I use USB wifi stick with mt7601u kernel driver and it works very good.
However after switch from USB power to battery I receive endles messages:
Code:
[   75.890362] mt7601u 1-1:1.0: Vendor request req:07 off:1700 failed:-110
[   79.122377] mt7601u 1-1:1.0: Vendor request req:07 off:1704 failed:-110
[   82.354362] mt7601u 1-1:1.0: Vendor request req:07 off:1708 failed:-110
[   85.586380] mt7601u 1-1:1.0: Vendor request req:07 off:101c failed:-110
[   88.818362] mt7601u 1-1:1.0: Vendor request req:07 off:170c failed:-110
[   92.050380] mt7601u 1-1:1.0: Vendor request req:07 off:101c failed:-110
[   95.282362] mt7601u 1-1:1.0: Vendor request req:07 off:1710 failed:-110

BBB cannot be switchoff even by powerbutton.
If bbb boots from battery is ok. See the power status
Code:
debian@beaglebone:/opt/scripts$ sudo ./powerstatus.py
Querying Beaglebone Black Power Management IC on i2c-0 device 0x24
On battery power only? 1

Charging Battery? 0


STATUS: r[0xa]=0x80

Push Button = 0
USB Power = 0
AC Power = 0


CHARGER: r[0x3]=0x0

Temp sense error = 0
Pre-charge Timedout = 0
Charge Timedout = 0
Active (charging) = 0
Charge Termination Current = 0
Thermal Suspend = 0
DPPM Reduction = 0
Thermal Regulation = 0


PGOOD: r[0xc]=0x7f

LDO2 power-good = 1
LDO1 power-good = 1
DCDC3 power-good = 1
DCDC2 power-good = 1
DCDC1 power-good = 1
LDO4 power-good = 1
LDO3 power-good = 1
The same if booted from USB power:
Code:
debian@beaglebone:/opt/scripts$ sudo ./powerstatus.py
Querying Beaglebone Black Power Management IC on i2c-0 device 0x24
On battery power only? 0

Charging Battery? 0


STATUS: r[0xa]=0x84

Push Button = 0
USB Power = 1
AC Power = 0


CHARGER: r[0x3]=0x1

Temp sense error = 1
Pre-charge Timedout = 0
Charge Timedout = 0
Active (charging) = 0
Charge Termination Current = 0
Thermal Suspend = 0
DPPM Reduction = 0
Thermal Regulation = 0


PGOOD: r[0xc]=0x7f

LDO2 power-good = 1
LDO1 power-good = 1
DCDC3 power-good = 1
DCDC2 power-good = 1
DCDC1 power-good = 1
LDO4 power-good = 1
LDO3 power-good = 1
I think the kernel has errors. I need to examine it as far as possible.
 
I would suspect the issue is that when USB power is lost, the USB port for the external wifi is also not powered properly anymore and for some reason the kernel driver cannot handle a sudden power loss of the device.


I would try the same test using ethernet network. If that works, one could test to extend the python script to somehow immediately remove the wifi driver once power loss is detected in an attempt to avoid hanging.
 
I would suspect the issue is that when USB power is lost, the USB port for the external wifi is also not powered properly anymore and for some reason the kernel driver cannot handle a sudden power loss of the device.


I would try the same test using ethernet network. If that works, one could test to extend the python script to somehow immediately remove the wifi driver once power loss is detected in an attempt to avoid hanging.

Thanks coroner21!
I did the test with Ethernet connected (and usb-wifi disconnected) and the script works fine E.g. BBB after switching from usb to battery power supply is shunting down properly in 5 sec.
Code:
debian@beaglebone:/opt/scripts$ sudo ./powerstatus1.py
beep
beep
beep
beep
beep
beep
beep
[  185.117769] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (88, <AValid), retry #3, port1 0008010c
[  190.260376] reboot: Power down

So we have an issue how to remove usb-wifi driver/module during transition from usb to battery power supply.

Some additional info about BBB and batery I found:
BeagleBone Power Management - eLinux.org
 
Member
Joined 2007
Paid Member
So we have an issue how to remove usb-wifi driver/module during transition from usb to battery power supply.

I wonder if we can't just suspend the USB port connection. Earlier kernels had more possibility for control and newer ones have less, so experimentation will be needed. Perhaps while running with ethernet you can try deactivating the WiFi via the command line. The wifi driver might play nice, or it might not... If you find a command that works we can just add that to the script prior to shutdown. Take a look on stack_overflow.

Controlling a USB power supply (on/off) with Linux - Stack Overflow

Edit - meanwhile I will think about using error management within Pythin

F.
 
Last edited:
I wonder if we can't just suspend the USB port connection. Earlier kernels had more possibility for control and newer ones have less, so experimentation will be needed. Perhaps while running with ethernet you can try deactivating the WiFi via the command line. The wifi driver might play nice, or it might not... If you find a command that works we can just add that to the script prior to shutdown. Take a look on stack_overflow.

Controlling a USB power supply (on/off) with Linux - Stack Overflow

Edit - meanwhile I will think about using error management within Pythin

F.
Thanks Frank
I've just tried:
Code:
sudo rmmod mt7601u
and with 'USB Power supply' it works:
Code:
debian@beaglebone:/opt/scripts$ lsmod
Module                  Size  Used by
mt7601u               106496  0
mac80211              737280  1 mt7601u
cfg80211              692224  2 mac80211,mt7601u
snd_soc_botic          16384  1
evdev                  24576  1
usb_f_acm              16384  2
u_serial               20480  3 usb_f_acm
usb_f_ecm              20480  2
usb_f_rndis            32768  4
u_ether                24576  2 usb_f_ecm,usb_f_rndis
libcomposite           65536  16 usb_f_ecm,usb_f_acm,usb_f_rndis
8021q                  32768  0
garp                   16384  1 8021q
stp                    16384  1 garp
mrp                    20480  1 8021q
llc                    16384  2 garp,stp
snd_soc_botic_codec    16384  1
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
iptable_nat            16384  0
nf_nat_ipv4            16384  1 iptable_nat
nf_nat                 36864  1 nf_nat_ipv4
nf_conntrack          159744  2 nf_nat_ipv4,nf_nat
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
iptable_mangle         16384  0
iptable_filter         16384  0
ip_tables              24576  3 iptable_mangle,iptable_filter,iptable_nat
x_tables               32768  3 iptable_mangle,ip_tables,iptable_filter
debian@beaglebone:/opt/scripts$ sudo rmmod mt7601u
debian@beaglebone:/opt/scripts$ sudo ./powerstatus1.py
beep
beep
[  110.910509] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (88, <AValid), retry #3, port1 0008050f
[  115.925057] reboot: Power down
I am curious whether the script with removal of the mt7601u when running on battery will work.
 
Member
Joined 2007
Paid Member
Good progress. I don't know if we can avoid the WiFi driver problems once the system involuntarily transitions to battery. What happens when you add this code after the battery sensing code in powerstatus.py?

Code:
    while True:
        try:
            if onBattery():
                system("rmmod mt7601u")
                system("shutdown -h now")
            else:
                print 'beep'
                time.sleep(2)
        except:
            e = sys.exc_info()[0]
            print( "Error: %s" % e )

I'm not 100% sure of the syntax on the exception - see what happens and we can tweak... Hopefully it will print any kind of error that the Python program encounters.
 
Good progress. I don't know if we can avoid the WiFi driver problems once the system involuntarily transitions to battery. What happens when you add this code after the battery sensing code in powerstatus.py?

Code:
    while True:
        try:
            if onBattery():
                system("rmmod mt7601u")
                system("shutdown -h now")
            else:
                print 'beep'
                time.sleep(2)
        except:
            e = sys.exc_info()[0]
            print( "Error: %s" % e )

I'm not 100% sure of the syntax on the exception - see what happens and we can tweak... Hopefully it will print any kind of error that the Python program encounters.
Unfortunately it's not easy. The system does not turn off and produce known messages:
Code:
debian@beaglebone:/opt/scripts$ sudo ./powerstatus1.py
[  337.637916] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (88, <AValid), retry #3, port1 0008050f
[  340.807612] mt7601u 1-1:1.0: Vendor request req:07 off:180c failed:-110
[  344.040313] mt7601u 1-1:1.0: Vendor request req:02 off:180c failed:-110
[  345.584847] mt7601u 1-1:1.0: Error: send MCU cmd failed:-110
[  348.124973] mt7601u 1-1:1.0: Error: send MCU cmd failed:-110
[  351.335750] mt7601u 1-1:1.0: Vendor request req:07 off:a804 failed:-110
[  354.567797] mt7601u 1-1:1.0: Vendor request req:02 off:a804 failed:-110
[  357.799811] mt7601u 1-1:1.0: Vendor request req:07 off:106c failed:-110
[  361.031934] mt7601u 1-1:1.0: Vendor request req:02 off:106c failed:-110
[  364.263928] mt7601u 1-1:1.0: Vendor request req:02 off:a804 failed:-110
[  367.495958] mt7601u 1-1:1.0: Vendor request req:02 off:1808 failed:-110
[  370.728013] mt7601u 1-1:1.0: Vendor request req:02 off:180c failed:-110
[  373.960074] mt7601u 1-1:1.0: Vendor request req:02 off:1018 failed:-110
[  377.192115] mt7601u 1-1:1.0: Vendor request req:02 off:1010 failed:-110
[  380.424163] mt7601u 1-1:1.0: Vendor request req:02 off:1014 failed:-110
 
Member
Joined 2007
Paid Member
Unfortunately it's not easy. The system does not turn off and produce known messages

Unfortunate... The USB bus protocol is apparently complex so that data doesn't get truncated when the system is busy. Perhaps another manufacturer might use that wifi component but supply a more trouble-free driver? My only other suggestion might be use a completely different wifi dongle...

Best,

Frank
 
OK. I did some experiments yesterday to revert automatic shutdown (on battery) in case of power loss.
The most promising was replacing some source files before compiling in the new kernel directory (to older one from 4.8.13). eg. tps65217.c, tps65217-regulator.c, tps65217.h, rtc-omap.c.

The shutdown works as well as MPD and squeezelite but at the same time some other services do not start properly (waiting to run indefinitely)
Anyway I decided to switch to BeagleBone Green Wireless (BBGW).I've just ordered one. It seems like BBGW is not susceptible to damage after turning off the power plug (like BBB). Then I wouldn't need a battery at all. I will see;)
BTW I dont know if Hermes board will fit. It seems that the large USB socket on BBGW is located dangerously close to the expansion header.
 
Last edited:
Member
Joined 2007
Paid Member
This seems like a very practical solution. Good luck with the conversion!
BTW I dont know if Hermes board will fit. It seems that the large USB socket on BBGW is located dangerously close to the expansion header.

That does look like a possible obstacle. If you use a taller standoff and the Hermes pins are not long enough you can change them. One by one, just heat the short end and with a pliers on the long end pull the individual pin out through the plastic spacer. Times 40! :p. Then clean up with solder wick ribbon and flux...

Cheers,

Frank
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.