Hi,
Many thanks for your reply sir. I will indeed include some photographs and maybe a video of this strange behaviour at the weekend. I have tried 2 different max3232 converters, the one i am using currently is from SEEDSTUDIO and is linked below:
https://cpc.farnell.com/seeed-studio/103...s232%20ttl
It has leds to indicate tx and rx. I can clearly see the rx led receiving data every 2 seconds or so in standby (i assume this is some kind of "ping" from the mmi to the HU) and indeed can see the data being received on any touch of the buttons or jog dial.
RE the "core_freq=250" in config.txt; i have read in various places that this command was necessary on earlier os's in order to lock the cpu frequency when using the mini uart (the mini-uart is apparently affected by clock speed) , however, i believe the os now does this automatically when the "enable_uart=1" command is issued. it was just something i put in there in desperation and have removed it now but the behaviour is exactly the same. It is irrelevant now as i have disabled the mini uart and am using the PL011 full uart on the physical pins as I'm led to believe that the mini-uart suffers a number of compatibility issues.
The strangest thing about this fault is that it does work some of the time so i'm pretty confident that the wiring is correct. One road i am investigating down is the (unsusal?) settings for the data stream. I am led to understand that the MMI communicates via RS232 in an 8N2 with rx inverted. This i have discovered from the following thread:
https://github.com/rampage128/arduinoMmi
However, i can find no way of setting this particular baud/data rate for the pi. The thing that leads me to believe this may be the issue (although this could equally be a red herring) is the fact that quite often if a button is pressed a number of times in quick succession it will generally receive the command in OAP but seems to latch. For instance, if i press the bottom right button a number of times and get to the bottom bar, scroll (and scroll and scroll) to get to the volume slider and then press the scroll wheel inwards a few times, once the command is finally received it will act as if i was keeping my finger on the "enter" button on the keyboard; The volume slider alternates between lighter and darker orange at about 20hz. No other button will now have an effect until i roll the scroll wheel really quickly. Sometime i will catch it correctly and can change the volume by doing loads of scrolls, or sometimes it will scroll left or right away from the volume icon. This is of course dependent on where it is within this "typematic cycle".
As i say, i will be happy to post some pictures when the weekend comes (i did put the glove box back in to try and shorten the wires in case interference was a problem so will need to take it out again. i am also now using belden 8132 screened cable at about 600mm length with the screen of the cable attached to the vehicle earth. This has also made no difference)
in the meantime, if any of you genii out there are reading this then maybe someone could shed some light on the setting of the baud rate on the pi? that might be helpful.
Also Mr BlueWave sir, was the script written by yourself for the MMI control? maybe you could tell me where this script is so that i can have a look at it and try to understand a little more how it works?
Congrats on the excellent software by the way, It really does appear like it will be awesome when i can get the MMI working as i am sick of arguing with google about what voice command i've just tried to give:-)
Regards
Bryan
PS I forgot to mention, when the jog dial is pressed in and does it's "latching" thing, I can see now from the LEDS on the max3232 that it is NOT receiving multiple commands; it's as if the software receives the "button pressed" but not the "button released" command, if this makes sense to someone? Not sure if this is quite how it works but it's the only way I can seem to articulate it
Many thanks for your reply sir. I will indeed include some photographs and maybe a video of this strange behaviour at the weekend. I have tried 2 different max3232 converters, the one i am using currently is from SEEDSTUDIO and is linked below:
https://cpc.farnell.com/seeed-studio/103...s232%20ttl
It has leds to indicate tx and rx. I can clearly see the rx led receiving data every 2 seconds or so in standby (i assume this is some kind of "ping" from the mmi to the HU) and indeed can see the data being received on any touch of the buttons or jog dial.
RE the "core_freq=250" in config.txt; i have read in various places that this command was necessary on earlier os's in order to lock the cpu frequency when using the mini uart (the mini-uart is apparently affected by clock speed) , however, i believe the os now does this automatically when the "enable_uart=1" command is issued. it was just something i put in there in desperation and have removed it now but the behaviour is exactly the same. It is irrelevant now as i have disabled the mini uart and am using the PL011 full uart on the physical pins as I'm led to believe that the mini-uart suffers a number of compatibility issues.
The strangest thing about this fault is that it does work some of the time so i'm pretty confident that the wiring is correct. One road i am investigating down is the (unsusal?) settings for the data stream. I am led to understand that the MMI communicates via RS232 in an 8N2 with rx inverted. This i have discovered from the following thread:
https://github.com/rampage128/arduinoMmi
However, i can find no way of setting this particular baud/data rate for the pi. The thing that leads me to believe this may be the issue (although this could equally be a red herring) is the fact that quite often if a button is pressed a number of times in quick succession it will generally receive the command in OAP but seems to latch. For instance, if i press the bottom right button a number of times and get to the bottom bar, scroll (and scroll and scroll) to get to the volume slider and then press the scroll wheel inwards a few times, once the command is finally received it will act as if i was keeping my finger on the "enter" button on the keyboard; The volume slider alternates between lighter and darker orange at about 20hz. No other button will now have an effect until i roll the scroll wheel really quickly. Sometime i will catch it correctly and can change the volume by doing loads of scrolls, or sometimes it will scroll left or right away from the volume icon. This is of course dependent on where it is within this "typematic cycle".
As i say, i will be happy to post some pictures when the weekend comes (i did put the glove box back in to try and shorten the wires in case interference was a problem so will need to take it out again. i am also now using belden 8132 screened cable at about 600mm length with the screen of the cable attached to the vehicle earth. This has also made no difference)
in the meantime, if any of you genii out there are reading this then maybe someone could shed some light on the setting of the baud rate on the pi? that might be helpful.
Also Mr BlueWave sir, was the script written by yourself for the MMI control? maybe you could tell me where this script is so that i can have a look at it and try to understand a little more how it works?
Congrats on the excellent software by the way, It really does appear like it will be awesome when i can get the MMI working as i am sick of arguing with google about what voice command i've just tried to give:-)
Regards
Bryan
PS I forgot to mention, when the jog dial is pressed in and does it's "latching" thing, I can see now from the LEDS on the max3232 that it is NOT receiving multiple commands; it's as if the software receives the "button pressed" but not the "button released" command, if this makes sense to someone? Not sure if this is quite how it works but it's the only way I can seem to articulate it
This is driving me insane