Forum Replies Created

Viewing 15 posts - 91 through 105 (of 108 total)
  • Author
    Posts
  • in reply to: "Controller mode not matched or no controller found" #1733
    Bill
    Member

    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.

    in reply to: arduino out put pins #1732
    Bill
    Member

    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.

    in reply to: All buttons on controller sending "255" #1731
    Bill
    Member

    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.

    in reply to: Stick Values #1730
    Bill
    Member

    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.

    in reply to: Not Receiving Data #1729
    Bill
    Member

    Did you connect all three wires between both Arduinos?

    in reply to: All Quiet on the western front… #1682
    Bill
    Member

    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.

    in reply to: Special PS2 Controller Not Talking #1681
    Bill
    Member

    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.

     

    in reply to: Controller mode not matched or no controller found #1680
    Bill
    Member

    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?

    in reply to: Pinout? #1679
    Bill
    Member

    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.

    in reply to: BUG ALERT: Memory Leaks? #1671
    Bill
    Member

    I’ll take a look at it this weekend.

    in reply to: Pinout? #1669
    Bill
    Member

    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, 4 months ago by Bill.
    in reply to: Special PS2 Controller Not Talking #1668
    Bill
    Member

    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.

    in reply to: SD file questions #1645
    Bill
    Member

    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.

    in reply to: Cominications Hub #1644
    Bill
    Member

    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?

    in reply to: ACKnowledgment for EasyTransfer #1643
    Bill
    Member

    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.

Viewing 15 posts - 91 through 105 (of 108 total)