Go Back   Home > Forums > > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Twisted Pear Superior quality electronic kits

Reply
 
Thread Tools Search this Thread
Old 10th June 2018, 08:25 PM   #81
Russ White is offline Russ White  United States
diyAudio Member
 
Russ White's Avatar
 
Join Date: Jan 2005
Location: Nashville, TN, USA
Hmm - you could have some DC on your mains - an isolation transformer can help for that. Otherwise you might just need better shielding. Large ground bounces can wreak havoc on your gear.

Also - you can detect when a reset occurs and then respond by re-initializing to your desired state.
__________________
Less pulp more juice Twisted Pear
Audio
/Twisted Pear Audio Blog
  Reply With Quote
Old 29th June 2018, 07:21 PM   #82
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Quote:
Originally Posted by Russ White View Post
Hmm - you could have some DC on your mains - an isolation transformer can help for that. Otherwise you might just need better shielding. Large ground bounces can wreak havoc on your gear.

Also - you can detect when a reset occurs and then respond by re-initializing to your desired state.
Been away traveling but now back on this issue. Two things:

1. I added (what I hope is) a decent multi-stage power filter to the BBB/DAC plus the switching power supply for the external chassis fans. I also put the amps on a better surge suppressor. Still gathering data. I don't claim to know everything that could go wrong.

2. I've been studying my Python, and have now modified the control program for the system so that it runs in multiprocessing mode. This allowed me to add a 'police' function that checks one register in each of the 9028s at fixed time intervals (trying 0.3 seconds). The question is, what is the best register to monitor in this situation? The ultimate problem is DC going to the speakers. I don't really know if that has been caused by a full DAC reset or just some registers being disturbed. For various reasons I suspect the latter. Otherwise, why would only one of two tweeters fry? So I'm wondering if there is one register in particular to blame, because that would be the one to monitor. My guess would be register 15 somehow being knocked out of 'stereo mode'. It might be feasible to monitor two registers - I haven't tried. Any and all thoughts on this question would be appreciated. Pure speculation welcome!

Cheers,

Frank
  Reply With Quote
Old 30th June 2018, 01:23 PM   #83
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Quote:
Originally Posted by francolargo View Post
The question is, what is the best register to monitor in this situation?
Reflecting further on this, I would like to know the mapping of the 9028's 8 channels by Buffalo. Specifically, to the plus and minus sides of each differential output. I saw problems when I tried to tweak the relative volume of the left vs. the right channel using registers 16-23. If that were done incorrectly, could it 'unbalance' the output of a channel?
  Reply With Quote
Old 28th August 2018, 10:02 PM   #84
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Sporadic work on the problem of 9028 register stability is yielding some progress.

Unintended alterations of 9028 registers is still occurring. How? Still no clue. The 3 DAC boards are housed together in a rack chassis and the BBB is housed in a smaller chassis - the two are attached by a multi-function cable with 2X5v power and I2C connections. All the chassis casing is shielded to the same ground, with the 4 ft. power cable being completely surrounded by copper braid. I2S signals travel through separate cat6 cables via teleporters. I placed a power conditioner on the power plugs to the DAC chassis - 10A Two Outlet Power Conditioner | Furman Power | Purifying power for over 40 years. That made an improvement - now it seems that the main source of interference is the power switches to the 6 amp channels. They have large power supplies, and they are protected by their own separate surge suppressor - 6 Outlet, 2x3 Pro Surge Suppressor Strip | Furman Power | Purifying power for over 40 years.

I have been tweaking the Python program that controls the system's core functions. To prevent damage to the drivers, I've been monitoring register 15 of each 9028 three times per second to assure stereo mode is maintained. If that register becomes corrupted I reset all of the important registers. It worked pretty well until once the I2C function quit and then some heat damage occurred - but not to expensive drivers. Now I also monitor for proper I2C function, and if that is lost then the BBB immediately kills the process running whatever player is producing I2S. So far, so good... However, amps must be turned off before hard resetting the DACs to prevent major thumps!

We're getting there... Next step is to incorporate diagnostic logging into the Python control program. Then data can be collected without real-time monitoring from the command line. That will allow me to gain sufficient confidence before risking damage to 'good drivers'. But even with the temporary setup, the sound is SO GOOD! It will be truly worth the effort to overcome these thorny issues.

Ideas, thoughts, comments? Please speak up. Especially any of you engineers!

Frank
  Reply With Quote
Old 7th January 2019, 05:04 AM   #85
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Hi Twluke and those interested in control of the es9028/38 via I2C:

I placed some example code on GitHub HERE. It is NOT ready to run - unfortunately I can't take the time to test it now and it needs to be changed to initialize the DAC in the way twluke prefers. After that is done it should be OK to try running it from the command line of a BBB; simply type 'python DACserver.py' from the source directory in which the code is located.

The first thing that will happen is various helper programs for Python will be loaded.
Second, the DAC will be initialized.
Third, a server program will be started to listen for text commands. You can enter them via a second ssh window using netcat - something like 'nc localhost 8192' where 8192 represents the port number. Then you can type control text followed by 'enter', which is anything the python server function can recognize. In this case, it can listen for: "set it to XXX" where the x's represent volume; "mute" and "unmute"; plus 6 different functions that, as written, change the type of filter used for 8x FIR interpolation. These are just simple examples. I am also using this text-based server function to initiate or kill BBB programs, change indicator LEDs, and route input signals using TPA's Otto board.
Finally, the code includes a (disabled) 'police' function that will examine register 15 to be sure it is in stereo mode. That can be used to cause a soft-reset or kill a BBB process (like a music renderer) if something goes wrong with I2C functioning.

Take a look and ask any questions at all...

Best,

Frank

Last edited by francolargo; 7th January 2019 at 05:20 AM.
  Reply With Quote
Old 7th January 2019, 02:45 PM   #86
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Another way to use netcat in a separate ssh login window is:

echo 'your text here' | netcat localhost 8192

Note that Python lines 177-179 are comments here, but in my case I use 4 ports rather than just 8192. Then my various controllers that are running NetIO do not conflict with one another.
  Reply With Quote
Old 7th January 2019, 10:33 PM   #87
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
mini update: The DAC configuration script (over on GitHub) is working correctly to configure one of my B3Pros as suggested. Unfortunately, the server function to control the options is not responding correctly. Apparently I chopped something out that I need to restore. ...working on it as time permits.
  Reply With Quote
Old 8th January 2019, 03:07 AM   #88
twluke is offline twluke  Japan
diyAudio Member
 
Join Date: Nov 2012
Location: Tokyo
Control of BBB-based audio appliances
Quote:
Originally Posted by francolargo View Post
-snip-
After that is done it should be OK to try running it from the command line of a BBB; simply type 'python DACserver.py' from the source directory in which the code is located.
Hi Frank, thank you for guiding me to this thread. Well, on BBB I tried this command line but I got errors like below:
Code:
root@arm:~# python ./DACserver.py
Traceback (most recent call last):
  File "./DACserver.py", line 31, in <module>
    dacregister()
  File "./DACserver.py", line 16, in dacregister
    bus.write_byte_data(0x48, 0x07, mutebus)  # mute
NameError: global name 'bus' is not defined
Am I missing something? TIA
  Reply With Quote
Old 8th January 2019, 05:08 AM   #89
francolargo is offline francolargo  United States
diyAudio Member
 
Join Date: Mar 2007
Location: Twin Cities, MN
Hi Twluke,

Change line 16 to: bus.write_byte_data(0x48, 0x07, mute) # mute

Again in the GitHub version of DACserver.py, the DAC initialization seems to be working but the server function to change settings on the fly is not working - though it does work in my own system. Mine is far more complex, and not worth your time to investigate: 3 B3Pros, BBB control of inputs, outputs, and player software in addition to I2C. So, it could be a while before I find the problem and get it corrected. ... probably a couple of days minimum, with my current schedule.
  Reply With Quote
Old 8th January 2019, 06:32 AM   #90
twluke is offline twluke  Japan
diyAudio Member
 
Join Date: Nov 2012
Location: Tokyo
Control of BBB-based audio appliances
Quote:
Originally Posted by francolargo View Post
Hi Twluke,
Change line 16 to: bus.write_byte_data(0x48, 0x07, mute) # mute
Thanks for this info but, sorry to say, it didn't work.
Code:
root@arm:~# python ./DACserver.py
Traceback (most recent call last):
  File "./DACserver.py", line 31, in <module>
    dacregister()
  File "./DACserver.py", line 16, in dacregister
    bus.write_byte_data(0x48, 0x07, mute)  # mute
NameError: global name 'bus' is not defined
Quote:
So, it could be a while before I find the problem and get it corrected. ... probably a couple of days minimum, with my current schedule.
It's quite okay. I'm not in hurry. Thank you.
  Reply With Quote

Reply


Control of BBB-based audio appliancesHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Adding a volume control to a TPA3122-based audio kit i336 Class D 2 9th June 2015 07:50 AM
How do I use my appliances on a Furman PL8CE? Akins Equipment & Tools 21 20th May 2015 06:24 PM
Powering non-speaker appliances with an amp cspirou Everything Else 4 4th November 2014 11:34 AM
Household Appliances repair forum Tarzan Everything Else 7 22nd August 2012 08:54 PM
Transformer-based volume control wboyd Analogue Source 4 18th August 2004 05:57 PM


New To Site? Need Help?

All times are GMT. The time now is 03:03 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 14.29%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Copyright ©1999-2019 diyAudio
Wiki