UART communication between Pico and DY-HV8V audio module

[jeffdavis503]

I am trying to send commands to the audio board. The protocol uses a string of hex bytes

AA [Command] [Length] [data] [CRC]

from machine import UART, Pin
from time import sleep
uart = UART(0, 9600, tx=Pin(0), rx=Pin(1), bits=8, stop=1, parity=None)
uart.write(b'\xaa\x07\x02\x00\x01\xB4)

But nothing happens. Even if I send

uart.write(b'\xaa\x01\x00\xab')
sleep(1)
print(uart.read())

I get None back. Not sure what I am doing wrong?

[robert-hh]

First of all, the GND connection between the RP2040 and the audio board seems missing.

[robert-hh]

That's good. At least no random noise on the RX line. If I read the instructions right, the DIP switches have to be set to UART mode as 0-0-1. I cannot tell, if "ON" at the DIP switch is 1 or 0. So you could try to flip them to the opposite position.
What I could not tell from the user manuals is the level of the UART signal. You could check the standby levels of the DY-HV8F UART pins by setting the RP2040 pins 0 an 1 to GPIO input mode and reading back the levels.

[jeffdavis503]

I swapped the DIP switch settings with no change. I've seen a number of documents that show the ON is 1 so I am pretty sure that setting is correct. Setting the pins to input and reading the values returns 0 and 1 for pins 0 and 1 respectively. not sure what that indicates?

[robert-hh]

It seems to show that UART dors not have to be inverted. Do you wait sufficiently long after sending a command before trying to read?
Edit: I see, in the example above you wait 1 second, which is sufficient.

[jeffdavis503]

what do you mean that UART does not have to be inverted?

[robert-hh]

Sometimes chips use variants of the UART communication, like inverted levels (standby level is low instead of high) or reverse bit order. I do not have the data sheet of the board you use, so I cannot tell definitely.
Looking through various pages on the web it may be that the device runs at 5V logical level. Then a level shifter might be required at least for the connection RP2-TX to DY-HV8V RX. If you have a multimeter, you could check the voltage levels of the DY-HV8V TX pin.

[scruss]

Is this the same DY-HV8F module you asked about here: DY-HV8F audo module in UART mode - Raspberry Pi Forums?

This board seems to use the same command set as the XY-V17B board that we seemed to deal with on this thread on the Raspberry Pi board: Re: Changing Hex String

[jeffdavis503]

yes the same post. I was trying from the Raspberry Pico side and the MicroPython side to get help.

The thread that you pointed to is interesting and I tried all of the suggestions but nothing worked.

I get no response when I send the hex values. The Audio board is set in UART Mode and am able to play the file in a loop if I set it to MP3 play mode where it loops through all the files. SO I know the audio file and the speaker and board are working fine.

It has something to do with the UART commands between the DY-HV8F board and the Pico. I have TX ->RX and RX ->TX between the boards and have a common Ground wire between them too.

and from everything I have seen this command should play 00001.mp3 from the board

uart.write(b'\xaa\x07\x02\x00\x01\xB4')

[scruss]

did you try sending

b'\xaa\x0b\x01\x02\xb8'

before your play command?

This command selects the onboard flash from your device. Maybe that's needed to get things going?

If all else fails, try UART 1 on GPIO4 and GPIO5. Maybe the UART 0 pins are damaged?

I can't think of anything else we could try. I don't have one of these players, so I can't try things out

[jeffdavis503]

I ordered another Pico and wired it up and it worked first try. I am guessing the UART 0 pins are damaged on the other board?

[jeffdavis503]

I went back to the original PICO and wired up the UART 1 pins 4 & 5 and that worked too. So there must be an issue with UART 0 pins 0 & 1?

One thing that I did differently on the new PICO is that I soldered pin headers to Pin 0, 1 and grd and wired pin headers to the audio board and then used jumpers to wire it up. Since that worked I went back and soldered pin headers to the original Pico and tried it and it still failed on UART 0. But when I added pin headers to pins 4 & 5 when I tested it and like I said that worked.