Following these discussions it seems that there is some consensus that running sync mode offers sonic advantages. With a Cronus / BIIISE 9038 is that a simple as taking the Cronus master clock output and connecting to the ext MCK input in the BIII (and omitting the VDD XO Trident? Are there firmware changes needed?
Thanks in advance for any advice.
Thanks in advance for any advice.
That's correct.
Yes, a dedicated firmware is required for this sync mode setting. Check the comment from Russ. You'll need an AVR programmer to download the hex file to the firmware chip.
Regards,
That would be good decision. BTW, according to the post by Paul (aka JoeyDD), he could succeed in compiling a hex file of firmware supporting both of SPDIF/async and SyncMode (128fs). If interested, you might want to contact him.
Also, Russ may be busy in writing new firmware which might suffice your demand.
Regards,
I am still really confused at the way the Muxer hooks up, I know you all probably think I am being a bit dim here but the documentation is a bit oblique for me. Boards are built, I see the way the 4:1 mux board connects 4 x BNC 75ohm BNC sockets to the single input on the dac... got that.
So vcc and gnd connect to a 3.3v psu for LEDS
S0 S1 What is this?
If all four pins connect to the switch board then how do I get power in? Or is the power from the pin headers for connecting the boards and I wire the power in via the screw terminals on top?
What are the extra header cable and pin header bits unused in the bag for? Looks like another set
So vcc and gnd connect to a 3.3v psu for LEDS
S0 S1 What is this?
If all four pins connect to the switch board then how do I get power in? Or is the power from the pin headers for connecting the boards and I wire the power in via the screw terminals on top?
What are the extra header cable and pin header bits unused in the bag for? Looks like another set
Last edited:
Muxer all in and working I independently powered it with a spare half of a LCDPS I have but was wondering as I am going to need that soon to power a raspberry pi, can I use the 3.3V pins on the buffalo to power this small Muxer circuit?
It was making an evening of great music the other night i accidentally broke the 1.2v vreg (silly mistake) but will fix it and also buy a replacement untit just in case.
Am at the stage between cardboard box and case... everything nice and locked down on a tray.
It was making an evening of great music the other night i accidentally broke the 1.2v vreg (silly mistake) but will fix it and also buy a replacement untit just in case.
Am at the stage between cardboard box and case... everything nice and locked down on a tray.
My previous DAC was a Devialet D200 but I really felt it’s proprietary nature was worrying for the future and I went back to valves anyway because I like the sound more. I then got a HiFiBerry DACPro (the balanced one, didn’t like that at all) and then tried an Allo Piano 2.1 with Kali and Isolator, better. Am going to keep the Piano on its own for another Kodi installation and as a reality check about just how far forward this dac it is and move the Isolator with the Kali with touch screen and Volumio for an open ended dac solution.
Last night, had the touch screen working with Kali just before I broke the 1.2V vreg (oops) I am a bit clumsy and at the edge of knowing exactly what I am doing, but it’s all good learning stuff...
Last night, had the touch screen working with Kali just before I broke the 1.2V vreg (oops) I am a bit clumsy and at the edge of knowing exactly what I am doing, but it’s all good learning stuff...
An externally hosted image should be here but it was not working when we last tested it.
Last edited:
Nice work! Your layout is solid. I hope you get a lot of enjoyment out of it.
Cheers!
Russ
Thank you, I am not an expert like a lot of people here and I am breaking things and mis-setting things because I stay up too late and push too many changes at once. It sounded just phenomenal though, my goodness Propellorheads Decksanddrumsandrockandroll was just laid completely bare and things submerged in the soundfield became crystal clear... Blur’s Think Tank has a lot of recordings of things in other rooms that you can hear so easily now and it sound like it’s in another room and not a recording of another room — if that makes sense and Plaid’s Rest Proof Clockwork is a deep dive into sampled details that is just hash on lesser DACs....
It was all working just fine until I added the Isolator and the touch screen then it started to distort and only on one side, distorted, the Placid started doing weird things like outputting 15v on the - side and just 8V on the + side, but unhooking the 1.3 regulator brought both sides back to +/-15V I think I messed things up settings wise on the dip switches again and then taking reading from the 1.3v regulator there was a little snap and the magic smoke came out...
I briefly hooked up a 1.3V regulated supply from a LCDPS (briefly, that a lot of heat to shunt) just to be sure the DAC light blinked on and locked and after that just ordered another regulator...
Up late, get sleepy, try to push too fast, the result is getting into a tangle... hopefully I can solve the problems and get this safely in its case before too long.
It was all working just fine until I added the Isolator and the touch screen then it started to distort and only on one side, distorted, the Placid started doing weird things like outputting 15v on the - side and just 8V on the + side, but unhooking the 1.3 regulator brought both sides back to +/-15V I think I messed things up settings wise on the dip switches again and then taking reading from the 1.3v regulator there was a little snap and the magic smoke came out...
I briefly hooked up a 1.3V regulated supply from a LCDPS (briefly, that a lot of heat to shunt) just to be sure the DAC light blinked on and locked and after that just ordered another regulator...
Up late, get sleepy, try to push too fast, the result is getting into a tangle... hopefully I can solve the problems and get this safely in its case before too long.
Last edited:
Hi Paul,
I was wondering if you could provide some guidance on what you used to program the ATTiny ? I have the chips and the programming board and successfully configured the Arduino IDE to program the chip with the test 'blink' program.
My issue is now how to take Russ' files, make your modifications and then compile to a hex file and load to the ATtiny.
I assume that I would use AVRDude to send the program to the chip, but am unsure what is the best IDE for working with Russ' files from GitHub?
Any advice would be much appreciated.
Regards
Hi Martin,
What I did was that I downloaded the Master Sync Mode files from GitHub and then used them to create a new project using AVR Studio. I modified the the buffalo.c code and then built the program to get the hex file.
To program the ATTiny I first tried using and old Atmel AVR ISP programmer that I had (modified so that I can also power the ATTiny), but just couldn't get it to work. The alternative solution was a spare RPi3 running Raspbian and AVRDude. The ATTiny was plugged into a breadboard and connected to the RPi3's GPIO. I connected to the RPi3 via SSH and used terminal to program the ATTiny with AVRDude on the RPi3. It worked perfectly. You can have a look here: Overview | Program an AVR or Arduino Using Raspberry Pi GPIO | Adafruit Learning System. It explains step by step how to set everything up and then program using AVRDude.
Paul
What I did was that I downloaded the Master Sync Mode files from GitHub and then used them to create a new project using AVR Studio. I modified the the buffalo.c code and then built the program to get the hex file.
To program the ATTiny I first tried using and old Atmel AVR ISP programmer that I had (modified so that I can also power the ATTiny), but just couldn't get it to work. The alternative solution was a spare RPi3 running Raspbian and AVRDude. The ATTiny was plugged into a breadboard and connected to the RPi3's GPIO. I connected to the RPi3 via SSH and used terminal to program the ATTiny with AVRDude on the RPi3. It worked perfectly. You can have a look here: Overview | Program an AVR or Arduino Using Raspberry Pi GPIO | Adafruit Learning System. It explains step by step how to set everything up and then program using AVRDude.
Paul
Hi Paul,
Almost there - the only issue now is that for some reason AVRDude refuses to change the high fuse to 0xF5, it gives:
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xF5"
avrdude.exe: writing hfuse (1 bytes):
Writing | ***failed;
################################################## | 100% 0.06s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xF5:
avrdude.exe: load data hfuse data from input file 0xF5:
avrdude.exe: input file 0xF5 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0xd5 != 0xf5
avrdude.exe: verification error; content mismatch
The other fuses set fine and the program loads - at a bit of a loss here.
Regards
Almost there - the only issue now is that for some reason AVRDude refuses to change the high fuse to 0xF5, it gives:
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xF5"
avrdude.exe: writing hfuse (1 bytes):
Writing | ***failed;
################################################## | 100% 0.06s
avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xF5:
avrdude.exe: load data hfuse data from input file 0xF5:
avrdude.exe: input file 0xF5 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0xd5 != 0xf5
avrdude.exe: verification error; content mismatch
The other fuses set fine and the program loads - at a bit of a loss here.
Regards
Checking further the high fuse will set to other values, so it looks like the programmer wont accept the 0xF5 value which compared to the 0xD5 disables SPI on the chip. Looking at the datasheet the high fuse setting disabling SPI cannot be changed if the TinyAVR programmer is using SPI mode to program. I guess I will have to use another programmer to set that fuse.
Last edited:
To avoid this verification error, you might want to try to add a 10K R between Vcc and Reset and a 0.1uF C between Vcc and GND.
Regards,
Thanks I will try that but I think the issue is more fundamental and that the chip wont accept a fuse value that disables SPI when being programmed via SPI, the datasheet states the fuse byte high (SPIEN) is not accessible when programming with SPI. I guess a question for Russ is whether a setting of 0xD5 (which enables the same chip settings with the exception of not disabling SPI) would work.
Regards
Regards