[Bill]

Definitely need to try the resistors. They are connected like this:

One end of the resistors connects to the arduinopin with the data wire, the other connects to either 3.3V or 5V.

[Bill]

There’s a lot of theory you are missing out on to get your desired results. This first is Dead-Band. Most controllers don’t sit still very well when not being touched, so there numbers jump around a bit. If the value reported from the controller is suppose to be 128 when the stick is in the middle, it might jump around from 130 to 125 in real life. So you would have to write your code to say “If value is between 125 to 130, stop motors” to handle this actuality. This is the controllers dead band.

 

Hopefully this help. I don’t have time to write the code for you, but I can try to point you in the right direction.

[Bill]

Hmm, everything working fine but button pressures are always 255? Since you are using an official sony controller, my only guess is the controller is just bad. Hopefully button pressures were something you needed. I can tell you even when they do work, they are very twitchy and not consistent, so you aren’t missing out on much.

[Bill]

The example sketch only reports stick values when you hold down those buttons. You can access the values anytime from the library, that’s where your code comes in. The example sketch is just that, an example.

[Bill]

Did you connect all three wires between both Arduinos?

[Bill]

Mp3 files can be encoded with Variable bit rate, which mean every mp3 frame is a different bitrate. If the decoder is playing a VBR file, it would report different values every time it was polled for the bitrate. Could that explain

Just stuck on the bit rate not appearing constant.

[Bill]

Hmm, so you are trying to use this odd music based controller?

There’s signs of some communications in the debug. Makes me think adding pullup resistors and/or changing the clock speed may improve that problem. Follow the troubleshooting guide and see if anything changes.

 

[Bill]

Am i supposed to Acknoledge (9-Green) connected to the arduino?

No.

And did you try the rest of the troubleshooting steps, like slowing down the clock?

[Bill]

There’s no special rules for what pin needs to be where. Any IO pin can be used for any signal wire, as long as you setup the config function correctly.

[Bill]

I’ll take a look at it this weekend.

[Bill]

The reason I’m not explicit on which pins on the arduino to connect to is because any pin on the arduino can be used. As long as your code matches the physical hookup.

 

 ps2x.config_gamepad(13,11,10,12, true, true);   //setup pins and settings: 
GamePad(clock, command, attention, data, Pressures?, Rumble?) check for error

 

• This reply was modified 11 years, 9 months ago by Bill.

[Bill]

Hey Marsy,

I’ll take a closer look this weekend but don’t have your hopes up. If you read through the Curios Inventor reverse engineering article on the protocol he notes that different controllers seem to read the SPI bus in different ways. Only the official Sony controllers seem to be uniform, and that’s why I suggest only using them. The 3rd party controllers always have sporadic results.

[Bill]

Firstly, the SD and SdFat libraries only deal with 8.3 length file names, my understanding is that this means i cannot truncate the file names down to this using the arduino because they cannot read them correctly. Is there a way around this???

Not that I know of, but that’s a better question for someone in the SDFatLib developer group.

however i cant figure out how to get the file name.

Ok, there’s a lot to this. First create an array to hold the filename:

char playNext[] = “trackxxx.mp3”

A file on the SD card is just a long array of bytes to an Arduino. Your CSV file is no exception. It will look something like:

track001.mp3,track002.mp3,track003.mp3

and so on. Each song filename takes up 13 bytes of the file.  So if you want to play song 3 on your list you would have to open the CSV file and move the read index to 3×13 position in the file. (there’s a seekSet function on the sdfatlib that does this) This should set the index position at the letter ‘t’ of track003.mp3. Then you need to read in the 12 bytes of the song filename stored at that index. Like this:

track.read(playNext, 12);

Then playNext should have the full filename from that position in the CSV file.

[Bill]

So if I understand correctly, you want to send a packet of commands intended for the arm from the topside Mega to the ROV Mega which relays it to the arm controlling Arduino Uno?

Independent comms over the same serial port in opposite directions is no problem. Just create 2 library objects for each direction of travel, there’s an example of that included in the library. The same goes for multiple serial port, just create separate library objects initialized for different ports. You can get tricky if two serial ports are always going to deal with the same set of data and initialize the library objects with the same struct.

However the limitation is the library only handles one library object per direction of a serial port. So commands for the ROV mega and for the UNO arm must be in the same struct sent from the topside Mega. You could simple retransmit that struct with all commands to the Uno from another serial port on the ROV Mega and code the Uno to only deal with data in the struct that deals with the Arm. It would waste a little bit of RAM but not any CPU cycles.

Make sense?

[Bill]

It’s on my list for Easytransfer 2.0 with advanced options. Though because of my upcoming wedding I don’t have a time table for when that will be done.

In the mean time if you need an ack scheme it wouldn’t be too hard to implement.

if(ET.receiveData()) Serial.print(“A”); and on the transmitting end have it send data, wait a bit then look for an A coming back. If no A comes back send again.

[Author]

Posts