Results 1 to 7 of 7

Thread: Girder vs MSComm, different input through serial, why?

  1. #1
    Constant Bitrate
    Join Date
    May 2002
    Location
    Gorge of eternal peril
    Posts
    134

    Girder vs MSComm, different input through serial, why?

    Greetings, I am trying to implement direct support for my creative labs remote from my frontend without having to go through girder. Im using serial monitor to "spy" on the input through the serial port from both my program (using MSComm from within vc++) and girder. Girder produces 4d056798ac21 while mscomm produces 78FE80781E00F8807800F0800078FE7800F080 when the same key is pressed! I dont understand why this would happen. Shouldnt the same string be sent no matter what program is receiving? Any suggestions? The software that came with the remote "generates" the same string as girder, so it is some type of setting with the mscomm control.
    '03 BMW M3 6 spd.
    Black/Imola Red
    19's

    Shuttle XPC w/ AMD 1800+
    Opus 150w
    Lilliput 7"
    Wireless internet through my P900 and bluetooth

  2. #2
    FLAC
    Join Date
    Apr 2001
    Location
    Here, There, Everywhere
    Posts
    1,436

    Re: Girder vs MSComm, different input through serial, why?

    are both numbers of the same "base"?

    maybe your creative sends multiple sends in the case that inaccuracy occours? in that way girder 'rejects' bad codes?? I know when I was trying to hook just an IR receiver module directly to my parallel port (poor mans IRMan - and very bad!), I needed to write 'rejection' code into my then mp3car application to filter out the keypresses..... thats what the bulk of the IRMan's PIC chip does - filter out codes, but in hardware not software (thus not a load on the CPU)


    it just seems weird that spying on the com port doesnt give the same result.... have you tried monitoring the outgoing serial port line?? maybe Girder sends out some data back to the Creative remote to ACK that it received a IR keypress which you are not aware of?

    is there an initialisation procedure that needs to be sent to the creative remote receiver upon startup usage??? The IRMAN needs a "OK" string sent before the PIC chip will start to accept and forward on incomming keypresses...

    and finally, (and now I think about it, most likely), you dont have the Baud rate of the COM port set correctly in your VC++ test program to that the Creative Device expects.....


    hopefully one of them helps ya!!
    Project - GAME OVER :(

  3. #3
    Constant Bitrate
    Join Date
    May 2002
    Location
    Gorge of eternal peril
    Posts
    134
    Thanks for the reply!

    Yes, both numbers are hex, they both came directly via serial monitor.

    As far as I know, there is no init procedure, because both girder and the included software do not output anything through the port. No ACK or OK.

    At first I thought precisely what you suggested, that girder and the included software were filtering out parts of the message. But serial monitor should show the message before it even reaches these programs, so I should be getting the raw strings....

    The port settings has been set to "9600,N,8,1", which is the default, but when I spy on girder's init of the serial port, they are the same settings. The only thing that I can see is any different is the handshaking, but I tried all four of the handshaking options available to MSComm, and I couldnt seem to duplicate girders handshake init string. Could that be it?

    I have attached a shot of serial monitor showing all three programs and their input strings after pressing the same key, maybe that will help a bit. As you can see, nothing is sent out of the port. Anyway, thanks for the help!

    Edit: I also added links to the inits for both girder and my test app.

    Girder

    Test app

    Notice the reads at the end, that just keeps going and going. Both girder and the included software do that, MSComm doesnt... Maybe theres something there?
    '03 BMW M3 6 spd.
    Black/Imola Red
    19's

    Shuttle XPC w/ AMD 1800+
    Opus 150w
    Lilliput 7"
    Wireless internet through my P900 and bluetooth

  4. #4
    Raw Wave Rob Withey's Avatar
    Join Date
    Apr 2000
    Location
    Bedfordshire, UK
    Posts
    2,139
    Looks like a baud rate problem to me.


    Rob
    Old Systems retired due to new car
    New system at design/prototype stage on BeagleBoard.

  5. #5
    FLAC
    Join Date
    Apr 2001
    Location
    Here, There, Everywhere
    Posts
    1,436
    Originally posted by Rob Withey
    Looks like a baud rate problem to me.


    Rob

    it does doesnt it? Infix, im sure if you look around the net, someone has already done some interfacing with the device you are using...... are you sure its really 9600 baud and that maybe the spy program has it wrong? try changing the baud rate of your MSComm testing proggie and see if it is sucessfully reflected when you 'spy' on it.....
    Project - GAME OVER :(

  6. #6
    Constant Bitrate
    Join Date
    May 2002
    Location
    Gorge of eternal peril
    Posts
    134
    Ok so I looked again to verify, and it turns out girder and the other software run at 2400 baud. For some reason I overlooked that. Anyway, I changed the mscomm to 2400, and now it wont even receive anything! lol. I have no idea whats going on. Could it have something to do with the handshaking? Because that is the only other setting that I can see that is different.
    '03 BMW M3 6 spd.
    Black/Imola Red
    19's

    Shuttle XPC w/ AMD 1800+
    Opus 150w
    Lilliput 7"
    Wireless internet through my P900 and bluetooth

  7. #7
    FLAC
    Join Date
    Apr 2001
    Location
    Here, There, Everywhere
    Posts
    1,436
    well try changing that for sure.... without the correct "handshake" they aint gonna be able to talk to each other
    Project - GAME OVER :(

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •