visualapproach
Text
Hi,
Just wanted to let you know I just purchased a 2nd-hand IMIV, as I realy disliked al the secrecy regarding the text-part, so when it is arrives, i'll sniff the hell out if it, for my kodi-based carpc.
So expect some new insights shortly
Cheers, and clean program. Just a sugestion, in order to not block the melbus to long, a ISRtimer which replaces the long delays in the functions would be nicer, perhaps i'll for a version and implement it.
Sounds great! Looking forward to some open info on the subject. From what I've read about those adapters, they appear to use MD/MD-CHGR to send text. Unfortunately I have a HU-650 which don't let me simulate MD. It's got Ok sound but it appearently lacks support for anything but CD-CHGR and SAT radio.
Regarding the code - thanks for your words! I guess your referring to the functions "next song" and so on. I agree to that delays aren't the prettiest solution, but I don't think I'm stalling the melbus lines. Possibly missing out a message but the lines are generally not driven while waiting. I intentionally turned off timer0 (used for delay() and other timing ISR's.) because it might interrupt the communication. Although I think it will work with the timer turned on anyway since interrupts are turned off at the most time-critical parts of the code. The function delaymicros() doesn't depend on timer0 if delaying < ~1400 us. It would certainly be easier to make other time-related stuff with timers on. Do give it a try!
Thanks for posting!
Hi @visualapproach ,
as promised: https://github.com/VincentGijsen/melbus-sniffed-traffic
i'll continue to post more captures and deducted information.
Hi @visualapproach. I took your code, and flashed, hookedup my logic analiser in parallel. guess what, the first cmd, doesn't recognize the 0xC7 when its due... so therefore it doesn't fill in the blanks
I'm glad you also put effort into this! Together we might crack this! Now, can you tell me more about this? What cmd are we talking about. I guess, since you say 0xC7 that it is the master request broadcast? You saying that the arduino don't answer that? Or don't answer in the correct time? The arduino is definitely getting the master req broadcast and is sending an answer. But it might not be accepted by the HU. Please tell me more :-)
Indeed the Arduino doesn't reply after byte c7 has been called, it just logs 0xFF (as the Arduino is to late at T==3 to decide to fill in the bytes. It might be the whole-lot of init/reset-stuff just before the main while();
My guess is, that it's to slow or in between bytes. that while assessing, its bytecounter == 4, whilst its should be 3.
This might be due to the rather long command-list, by the time its evaluating the first statement, it might already be at byte 4?.
I think we might fake it with a 'special' case for the master-request, that when it's requested, we first stick some ms in the loop() to catch the 0x00 command for sure, although it might be ugly.
The other way, would be to nest while loops with the cases (on the ordered tree of commands), this would add an increase of speed, so it only has to evaluate the valid succeeding variants. But it would be far more messy...
In the meantime, i might port the code to a STM32, which has considerable more horsepower, which considering a busspeed of 10/12mhz with a 16mhz cpu, is cutting it close
About the STM32; I have one ready just in case. The initial goal for me was to show that a "slow" arduino could do it if you (ab)used it properly (not saying my coding is proper in any way, but it did the trick). Now I reached that goal for CD-CHGR, and with the more demanding SAT maybe it's time to reconsider the hardware. But it would be cooler to do it with an arduino.
I have several versions of "special case" and looping prior to what I posted here. It might be faster but it was so ugly that I couldn't understand it myself after a while :-D
I guess, its going to be, ugly loops or more horsepower. Perhaps moving the byte-compare logic to the interrupt handler to synchronise the checks, bit still, its a tight squeeze
It may be wise to develop with horsepower and when it works it might be portable to a pony.
Update: I got custom text in the display!! Working on improvement now.
Nice work. Just a small note: The HU-605 should accept the MD-CHGR. At least mine does with my attempt at an emulator (https://github.com/archi/melbus - that code only gets past the second init, but fails to properly reply with Disc/Track info. Probably the clock gen). I believe even the HU-403 I used as an indoor test device accepted it (not 100% sure, didn't work on this since 2.5 years)
EDIT: Mixed up the numbers. My HU-605 has MD, but not SAT. Don't know about HU-650.
great work u guys. i previously used Karl's code but wanted text..but i can't seem to get the text working on my HU-601..
@hu601 thanks, what is not working? Trying to help but your info is a little vague ;). Does your HU accept SAT mode at all?
Maybe someone have working code for STM32 for HU803 with working text in the display?
Would someone mind please posting a link to the code for text to screen using the MD emulation option? I've successfully programmed a PIC1842 using assembly language to emulate a CD changer but would prefer to tweak it to emulate an MD changer to get text onto the screen of my HU-613 (NB the PIC runs at 32 MHz and assembly is very efficient). I can follow code in C or pretty much any other language, within reason.
Hi harry,I don’t have a car anymore (with right hu) to sniff the traffic. Back then hu-850, which had SAT mode. You don’t happen to live in Netherlands, to hook up the aftermarket stuff and sniff exchange?BrSent from my phoneOn 14 Sep 2023, at 08:59, HarryBrunt @.***> wrote: Would someone mind please posting a link to the code for text to screen using the MD emulation option? I've successfully programmed a PIC1842 using assembly language to emulate a CD changer but would prefer to tweak it to emulate an MD changer to get text onto the screen of my HU-613 (NB the PIC runs at 32 MHz and assembly is very efficient). I can follow code in C or pretty much any other language, within reason.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
I'm in the UK. I might try following the same protocol as for the SAT unit to see whether I can get text onto the screen while emulating the MD changer, obviously changing the code identifier for the unit.