Silly question: Do you have SCLK going to UNO A5 and SDIO going to UNO A4?

 

Silly question: Do you have SCLK going to UNO A5 and SDIO going to UNO A4?

Sorry for the delayed response - I can go home and test these shortly. I do not have SCLK and SDIO going to A5 and A4 but I did try with that setup.

 

ok - I assume that you have a board with SDA and SCL pinned out. Anyways, those are things that I came up with - let me know how it goes.

 

ok - I assume that you have a board with SDA and SCL pinned out. Anyways, those are things that I came up with - let me know how it goes.

Changing the I2C speed routines did not do anything so I changed it back. Changing from 0 to INTpin caused the following to show up and nothing else:

*** Si4844 Quick Test **
...setting I2C speed to 10kHz
...resetting Si4844

 

Changing the I2C speed routines did not do anything so I changed it back. Changing from 0 to INTpin caused the following to show up and nothing else:

*** Si4844 Quick Test **
...setting I2C speed to 10kHz
...resetting Si4844

Try both together. That is, the new I2C speed commands and the INTpin command.

 

Try both together. That is, the new I2C speed commands and the INTpin command.

Both together is the same result. No frequencies displayed.

 

Both together is the same result. No frequencies displayed.

OK. I am out of ideas for the moment. It is very frustrating.

We have to make sure we can set I2C to 10
We have to make sure we can set I2C to 50
We have to make sure that the UNO is resetting the B20.
We have to make sure that the B20 will issue interrupts to the UNO

One or more of these is not working and we have to figure that out to move forward.

 

OK. I am out of ideas for the moment. It is very frustrating.

We have to make sure we can set I2C to 10
We have to make sure we can set I2C to 50
We have to make sure that the UNO is resetting the B20.
We have to make sure that the B20 will issue interrupts to the UNO

One or more of these is not working and we have to figure that out to move forward.

After changing everything back the frequencies on the serial monitor stop if I unplug SDA or SCL. Not sure if this helps but just an observation. I have no clue why it would set Band=3.

 

After changing everything back the frequencies on the serial monitor stop if I unplug SDA or SCL. Not sure if this helps but just an observation. I have no clue why it would set Band=3.

Not too surprising. The I2C reads are blocking so they will sit there.

I still wish you would try it with a promini 3.2v.

You have a change in the board and a change in the chip. Now, I can't see why it would not work because you have been pretty conscientious in addressing the differences...but it doesn't work.

Can you independently verify that the reset line is working? That is, look at the code where I simply toggle the reset line - if you run that in isolation, you should easily see that line toggle on a scope or even a meter.

Somehow we have narrow the search.

 

anything special going on with the crystal? Which one did you use? What about the two caps? I may be reaching, but if the crystal was bad, it might behave as it is behaving.

 

anything special going on with the crystal? Which one did you use? What about the two caps? I may be reaching, but if the crystal was bad, it might behave as it is behaving.

Same crystal and capacitors used in your setup - I have two crystals so I can swap it and double check. I am planning on trying the Pro Mini and if it works I will figure out how to get the UNO running with the scope.

 

Yeah, if it is easy enough to check, I say check it. I hate to just try everything and I wish that it were sitting here to check everything, but I do think we can figure this out.

Something else occurred to me. You have wire connections under the chip adapter board. I don't do that on a breadboard, but so long as they are insulated and you are still getting a good fit, I don't know as that it would cause a problem. If there was some bare metal on the lead and it was pressing on the traces (usually those adapter boards are double-sided), it would be an issue. This is just something that occurred to me and I am passing it on.

Getting a Pro Mini 3.3 is a good plan and I look forward to hearing about whether it makes a difference.

 

Yeah, if it is easy enough to check, I say check it. I hate to just try everything and I wish that it were sitting here to check everything, but I do think we can figure this out.

Something else occurred to me. You have wire connections under the chip adapter board. I don't do that on a breadboard, but so long as they are insulated and you are still getting a good fit, I don't know as that it would cause a problem. If there was some bare metal on the lead and it was pressing on the traces (usually those adapter boards are double-sided), it would be an issue. This is just something that occurred to me and I am passing it on.

Getting a Pro Mini 3.3 is a good plan and I look forward to hearing about whether it makes a difference.

I just finished hooking up the Pro mini and the radio is fully functional. For some reason modifying the code isn't working for the Uno.

 

I just finished hooking up the Pro mini and the radio is fully functional. For some reason modifying the code isn't working for the Uno.

Good Deal!

That the board works as it was designed with the ProMini 3.3v is a sanity check of sorts. It, essentially, eliminates a number of possibilities.

To move forward to get it working with the UNO, I think that you would need to systematically investigate the following aspects of the problem. I looked at these issues and nothing screams out at me, but, we are missing something. Obviously, I did not design it, or test it, with an UNO, but I also do not see why it can’t be made to work with one.

Voltage conversion for the four lines, RST, SDIO, SDCLK, IRQ.

You are using a decent level converter, but none is used with the ProMini, so you need to “manually” verify that each line is working as you think.

After verifying the level conversion, look at the role and function of each of those pins.

The RST line toggles the pin on the radio from the UNO. Timing is according to the datasheet. You have to check this, but I think that if the B20 is properly reset, it will issue an interrupt to the host to say “I am ready for action”.

IRQ is issued from the Radio to the UNO. An interrupt routine is attached in software so that the UNO pin produces an interrupt. You can insert a kind of breakpoint into the interrupt service routine to check whether it gets executed. As it stands, I am only setting a flag for the main program, again, as I recall. Thus, checking that flag state would tell you something about whether the pin interrupt on the UNO is working (simply printing out a message on the monitor when one is detected).

Note that I *think* that your UNO is receiving an IRQ, because you move through that first point in the program.

But, remember, if the I2C communication is not successful, the B20 may not be in the mood to be issuing interrupts beyond the first one.

SDIO/SDCLK for I2C.

It looks like this is where things are running amok. At either going to 10kHz and/or 50kHz or just I2C in general. We know that I2C on the B20 works since the radio works with the ProMini, so that is not where the problem is at. The problem is on the UNO side.

When reset, the B20 accepts only 10kHz I2C communication, so the UNO side needs to first be set up for that speed.

After a software dialog, as I recall from memory, the B20 can communicate at 50kHz. When the program gets to that point, the UNO has to change speeds again. I looked at your calculations once briefly and came up with the same numbers, but you need to verify those communication speeds.

One thing that I think that you can do to easily to see if there is I2C communication at the different speeds is to run an I2C scanner like this one https://playground.arduino.cc/Main/I2cScanner

Modify the code in setup() in the scanner by inserting code from the working code (including the hardware reset of the B20), but trying your calculations for the faster UNO. First, slowing it to 10kHz and then 50 kHz.

In each case, if the UNO side detects the radio chip, it will show a device at 0x11 (7 bit address). So, for example, you could insert code into the scanner program to change the UNO speed to 10kHz, reset the B20 and see if the scanner detects the B20. If so, than insert the code to change the UNO speed to 10kHz, reset the B20, then change to 50 kHz (just like the working code does) and see if the scanner can still detect the B20.

That is my thinking on moving forward now that things are working with the ProMini. If you do work on the conversion, please let us know. I am very curious to see what we missed!

 

Good Deal!

That the board works as it was designed with the ProMini 3.3v is a sanity check of sorts. It, essentially, eliminates a number of possibilities.

To move forward to get it working with the UNO, I think that you would need to systematically investigate the following aspects of the problem. I looked at these issues and nothing screams out at me, but, we are missing something. Obviously, I did not design it, or test it, with an UNO, but I also do not see why it can’t be made to work with one.

Voltage conversion for the four lines, RST, SDIO, SDCLK, IRQ.

You are using a decent level converter, but none is used with the ProMini, so you need to “manually” verify that each line is working as you think.

After verifying the level conversion, look at the role and function of each of those pins.

The RST line toggles the pin on the radio from the UNO. Timing is according to the datasheet. You have to check this, but I think that if the B20 is properly reset, it will issue an interrupt to the host to say “I am ready for action”.

IRQ is issued from the Radio to the UNO. An interrupt routine is attached in software so that the UNO pin produces an interrupt. You can insert a kind of breakpoint into the interrupt service routine to check whether it gets executed. As it stands, I am only setting a flag for the main program, again, as I recall. Thus, checking that flag state would tell you something about whether the pin interrupt on the UNO is working (simply printing out a message on the monitor when one is detected).

Note that I *think* that your UNO is receiving an IRQ, because you move through that first point in the program.

But, remember, if the I2C communication is not successful, the B20 may not be in the mood to be issuing interrupts beyond the first one.

SDIO/SDCLK for I2C.

It looks like this is where things are running amok. At either going to 10kHz and/or 50kHz or just I2C in general. We know that I2C on the B20 works since the radio works with the ProMini, so that is not where the problem is at. The problem is on the UNO side.

When reset, the B20 accepts only 10kHz I2C communication, so the UNO side needs to first be set up for that speed.

After a software dialog, as I recall from memory, the B20 can communicate at 50kHz. When the program gets to that point, the UNO has to change speeds again. I looked at your calculations once briefly and came up with the same numbers, but you need to verify those communication speeds.

One thing that I think that you can do to easily to see if there is I2C communication at the different speeds is to run an I2C scanner like this one https://playground.arduino.cc/Main/I2cScanner

Modify the code in setup() in the scanner by inserting code from the working code (including the hardware reset of the B20), but trying your calculations for the faster UNO. First, slowing it to 10kHz and then 50 kHz.

In each case, if the UNO side detects the radio chip, it will show a device at 0x11 (7 bit address). So, for example, you could insert code into the scanner program to change the UNO speed to 10kHz, reset the B20 and see if the scanner detects the B20. If so, than insert the code to change the UNO speed to 10kHz, reset the B20, then change to 50 kHz (just like the working code does) and see if the scanner can still detect the B20.

That is my thinking on moving forward now that things are working with the ProMini. If you do work on the conversion, please let us know. I am very curious to see what we missed!

I'll keep you up to date - I'm also trying to control the volume with a potentiometer and input with a rotary switch. Do you have any suggestions on how to add code to the test program or to change the final code to make that work? I haven't had much success in that area although I know the general approach. I'm plugging the middle pin of the volume control potentiometer into A0 on the pro mini and planning to use a resistor ladder for the input selector.

 

I would not suggest that you try to control the volume with a pot as you are describing. Volume is controlled digitally. You send commands to the chip. There are 64 volume levels.

Look at the main program, not the test program.You should be able to isolate the volume up/down routines. Even though they are linked to keyboard presses in the program, they call volume up/down routines (as I recall) and you should be able to figure out how to do it outside of the keyboard.

I connect the stereo out signals to amplified speakers and control the volume through the keyboard or on the speakers. I can't imagine that that tiny chip is going to be able to drive much.

Hope it helps.

 

I would not suggest that you try to control the volume with a pot as you are describing. Volume is controlled digitally. You send commands to the chip. There are 64 volume levels.

Look at the main program, not the test program.You should be able to isolate the volume up/down routines. Even though they are linked to keyboard presses in the program, they call volume up/down routines (as I recall) and you should be able to figure out how to do it outside of the keyboard.

I connect the stereo out signals to amplified speakers and control the volume through the keyboard or on the speakers. I can't imagine that that tiny chip is going to be able to drive much.

Hope it helps.

Thank you - I already have amplified speakers as well (very loud without volume control). For my project I am making an old fashioned radio and I have to use a potentiometer as described. I really want to try and make it work with the chip and I also want to get the rotary switch to select inputs. Definitely doesn’t seem easy but that’s what I have to do. I decided to stick with the pro mini until I get the whole radio working.

 

Thank you - I already have amplified speakers as well (very loud without volume control). For my project I am making an old fashioned radio and I have to use a potentiometer as described. I really want to try and make it work with the chip and I also want to get the rotary switch to select inputs. Definitely doesn’t seem easy but that’s what I have to do. I decided to stick with the pro mini until I get the whole radio working.

I would still suggest that you look at the routines for Vol up/down. Once you can understand how to work with the chip's command set, it will come together. If you have to have knobs, look into rotary encoders https://howtomechatronics.com/tutorials/arduino/rotary-encoder-works-use-arduino/

 

I would not suggest that you try to control the volume with a pot as you are describing. Volume is controlled digitally. You send commands to the chip. There are 64 volume levels.

Look at the main program, not the test program.You should be able to isolate the volume up/down routines. Even though they are linked to keyboard presses in the program, they call volume up/down routines (as I recall) and you should be able to figure out how to do it outside of the keyboard.

I connect the stereo out signals to amplified speakers and control the volume through the keyboard or on the speakers. I can't imagine that that tiny chip is going to be able to drive much.

Hope it helps.

But if he attaches the potentiometer to the Arduino and reads the setting via an analog read, it is easy to map the read value to the necessary digital commands.

 

But if he attaches the potentiometer to the Arduino and reads the setting via an analog read, it is easy to map the read value to the necessary digital commands.

I know the analogread() function gives values between 0 and 1023 (0 to 5V) for an analog potentiometer. If I can somehow scale this to be 0 to 64, shouldn’t it work with the chip?