# RNS-E: Albumart, Audible POI Alert, SDCard Maps* + MORE



## pcbbc (Sep 4, 2009)

*SDCard Maps on 192 units currently in Beta

I'm proud to announce my RNS-E firmware with optional Feature Pack purchase to enable exciting new features for RNS-E owners...

MP3 Album Art
Audible POI Alert
Custom Splash Screens
SD Card Maps (192 in beta)
Digital Speedo (mono DIS only)
Custom Map Colours
SDHC Card support for 192 units (in beta)
SDXC Support for 193 units (up to 256GB)
VIM Unlock
Plus the return of full 7-digit UK postcode lookup and custom POI.

Visit RNS-E Firmware for details and to download our custom RNS-E firmware.

Have as Great Christmas as the current situation allows, and stay safe on and off the road folks.

Stuart.


----------



## MT-V6 (Jan 11, 2015)

Good stuff!

I've yet to set this up, I must get around to that 

[smiley=cheers.gif]


----------



## SwissJetPilot (Apr 27, 2014)

When you say "_SDCard Maps for 193 PU units only_", how would I know which version of RNS-E I have in my 2007?

Any chance of a YouTube instructional video for how to make this work?


----------



## pcbbc (Sep 4, 2009)

SwissJetPilot said:


> When you say "_SDCard Maps for 193 PU units only_", how would I know which version of RNS-E I have in my 2007?


*192/193 PU Identification*
193 PU: MY2010 on - Media Button, 32GB SDHC card support, 800x480 LED high res screen
192: Prior to MY2010: CD/TV button, limited to 4GB non-HC SD cards, 400x240 LCD screen

So SJP: If it's original factory fit, you have a 192 (prior to 2010).

Full identification guide on the front page of my site.
You can check in the enginnering menu General -> Version screen if you are unsure.

*Installing New Firmware*
Instructions for burning new firmware here.

*Instructions for POI Update / SD Maps*
Video for how to add cosutom POI from the original NavPOInt launch...




For the 193 PU units you now also get a new option to author to SD Card (see screenshot in first post).
Edit: PDF Instructions

You will receive a licence key for your RNS-E to fully enable the new features, and for use with NavPOInt along with your Feature Pack purchase.


----------



## SwissJetPilot (Apr 27, 2014)

So looking at my RNS-E label on top of the case, is this where I find the 192 or 193 number?


----------



## pcbbc (Sep 4, 2009)

SwissJetPilot said:


> So looking at my RNS-E label on top of the case, is this where I find the 192 or 193 number?


Yes, that's another way to tell: Last 3 digits of Audi part number.
You can get that either from the label, or via VCDS.

You have a 192, so unfortnately SD maps are not possible.
The 192 is limited to 4GB SD Cards with very slow access speed, so fitting a 6/7GB map DVD on them just isn't going to work...

Sorry!


----------



## SwissJetPilot (Apr 27, 2014)

No worries. I'm just happy to have a reverse camera! 
But your software is a fantastic addition for those who can take advantage of what you've come up with.
Well done!


----------



## motornoter (Jul 16, 2012)

Hi PCBBC

Like SJP, I'm impressed with your software updates and by looks of it have a 192 unit. Does this mean I can input 7 diget poscodes after updating the system? Or is that only available on the later versions?? Will have a go at downloading anyway so thanks for all the hard work!!


----------



## pcbbc (Sep 4, 2009)

motornoter said:


> Like SJP, I'm impressed with your software updates and by looks of it have a 192 unit. Does this mean I can input 7 diget poscodes after updating the system? Or is that only available on the later versions?? Will have a go at downloading anyway so thanks for all the hard work!!


Thanks.

The problem with 192 units is you will need the ability to burn an updated DL DVD, which is not at all easy for the RNS-E.
But yes, if you can do that, then all features listed (bar obviously SD Card maps) are avialable on *both* the 192 and 193 PU units.

That includes custom POI and full 7-digit UK postcodes. Both these features require updated firmware *AND* updated navigation media (with the new data on it).


----------



## SwissJetPilot (Apr 27, 2014)

@ *pcbbc* - For those of us who lack the technical skills, do you offer this as a service if we shipped our RNS-E to you?

If so, what would you charge to do this?


----------



## pcbbc (Sep 4, 2009)

SwissJetPilot said:


> @ *pcbbc* - For those of us who lack the technical skills, do you offer this as a service if we shipped our RNS-E to you?
> If so, what would you charge to do this?


Just to upgrade the firmware? If you pay for postage and insurance both ways, then probably nothing?!

However upgrading the firmware is as easy as burning a CD with the update on it and inserting it in the RNS-E...
I would suggest it would be a whole lot easier for me to send you a CD (if you really cannot burn this this yourself) than for you to send me your RNS-E!

I'd have a minimal charge for that to cover costs. Probably aroun £/€10 should cover a CD and postage and packing.


----------



## SwissJetPilot (Apr 27, 2014)

Ah, okay. Much easier than I envisioned. Sounds like a pretty sweet deal!

Hopefully we can convince you to demonstrate it's capabilities on a YouTube video. I would imagine there are a lot of people who would be very interested to see what it looks like, especially with the ability to change splash screens.

Doesn't have to be anything fancy, just a nice GoPro or smartphone video would suffice.


----------



## motornoter (Jul 16, 2012)

I'm deffo up for that too!! Look forward to seeing the video.


----------



## Jezzie (May 24, 2020)

Putting the maps on SD is a real game changer for me! The dvd drive is intermittent and so I keep a spare Tom-Tom in the boot in case I get lost somewhere! Ok, ok, I do have a smartphone but there was no resale value in the TomTom!
A good Xmas present to myself, thanks!


----------



## SwissJetPilot (Apr 27, 2014)

@ *Jezzie* - Without taking anything away from this outstanding upgrade for an RNS-E, I use a Tomtom too.

*DIY - Vent Mount for GPS and/or Smartphone*
https://www.ttforum.co.uk/forum/viewtop ... &t=1930775


----------



## barry_m2 (Jun 29, 2015)

pcbbc said:


> Make sure you have the Map SD Card in slot 2 (right hand side).
> Make sure you have placed the supplied licence.key file in the root directory of the SD card in slot 1 (left hand side).
> If you only have one SD Card available you can also, but less ideally, place the licence.key file on the Map SD Card.


Hi, just want to ask a question on the quote above from your website. Is there an issue with the licence file being on the card in slot 2? What makes it less ideal?

Not a game changer, just wandering what the issue is?

Also, does the Album artwork display if I play music via Bluetooth through the Tune2Air dongle?

Cheers


----------



## SwissJetPilot (Apr 27, 2014)

@ *pcbbc* - Question about splash screen -

_Supported Splash Screen Format
The splash.bmp file must be a 32bpp uncompressed bitmap file. The image size must be exactly 400x240 for the 192 RNS-E, or 800x480 for the 193 RNS-E._

• Is this the 400x240 / 800x480 pixels?
• In which format should the image be saved; BPM, PNG, JPG or GIF?

The reason I'm asking as this states _"bitmap file"_, but the files in the zip file linked in the page below are all PNG. (https://rnse.pcbbc.co.uk/custom_splash.php)


----------



## pcbbc (Sep 4, 2009)

Hi SJP,

Yes, pixels. BMP format only. There are some sample images on the website, although only for 193 units.

192: 400x240 pixels in Windows BMP format with 32-bpp (bits per pixel).
193 PU: 800x480 pixels in Windows BMP format with 32-bpp.

For the graphic desingers out there who understand image formats the RNS-E display is actually only 16-bit per pixel RGB555. But since most non-pro graphics packages (paint.net, etc) do not support saving as 16-bpp, the firmware accepts 32-bpp ARGB8888 images as a convenience. It then downsamples the colours to RGB555 format.


----------



## SwissJetPilot (Apr 27, 2014)

Thanks!


----------



## pcbbc (Sep 4, 2009)

barry_m2 said:


> Hi, just want to ask a question on the quote above from your website. Is there an issue with the licence file being on the card in slot 2? What makes it less ideal?


The licence key file needs to be read after a cold boot to enable the feature pack. If the maps and licence key are on card 2, and you have just booted the RNS-E and inserted a freshly prepared map SD card, it' won't have read the licence file yet.

Usually that means the unit fails to recognise the maps SD card the first time it is inserted because it thinks it is unlicenced. Hence the insert, remove, re-insert advice.

So the only reason for this advice is a) users like a definitive answer, and b) it makes it easier to support. Best advice would probably be to put key file on ALL cards you intend to use in the RNS-E! Then even if you temporarily remove one, the licence can still be found and read...



> Also, does the Album artwork display if I play music via Bluetooth through the Tune2Air dongle?


Sorry, no. Albumart only from sources where the RNS-E actually has access to the raw MP3 data. Basically that's MP3 CDs and SD Cards only.

All other audio sources (Tune2Air, external CD changer, AMI, AUX, etc) provide pre-decoded analogue audio input to the headunit. There's therefore no physical way to transfer any albumart present in the original digital source files over to the RNS-E for display.


----------



## MT-V6 (Jan 11, 2015)

Just ordered a couple of 32GB memory cards, I rarely use mine and realised that they were only 4GB

Does anyone know if there is a 2021 navigation DVD available from Audi?


----------



## piti (Oct 10, 2018)

Nope, 2020 is the last one.

Peter


----------



## pcbbc (Sep 4, 2009)

KIWI was an attempt at an open format mapping system. I'm wondering if any of the other manufacturers that used it are still producing updates. I think Toyota stopped in 2018.

If they are then there's a posibility of being able to perhaps convert their maps to make it compatible with the RNS-E.

As for converting some other map data, from a completely unrelated system - No chance.


----------



## IPG3.6 (Sep 5, 2015)

Awesome work pcbbc!!!

Looks really good and gives new life to the OEM unit.


----------



## pcbbc (Sep 4, 2009)

Thanks IPG. Nice to be appreciated 

Happy Christmas everyone. Enjoy as best you are able.


----------



## Llewkcalb (Jul 15, 2019)

Pcbbc

Well done on continuing the project.

Could you elaborate on the rear only ops feature please.

I have module 8P0-919-475 which has ops enabled. The rns has ops enabled.

I was under the understanding it was not possible to have rear only and noted by mtv6's retrofits of front sensors.

Thanks

Steve


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> Pcbbc
> 
> Well done on continuing the project.
> 
> ...


Well, for an A2 user I made an Arduino board which connects to that vehicles 8Z0-919-283 PDC module via K-Line diagnostics and gets the sensor data. That's necessary because the 8Z0 module doesn't send any OPS data over CAN itself as far as I can tell (it just wasn't designed to work that way). The Arduino then injects the necessary CAN signals to fool the RNSE into believing the correct 8P0-919-475 module is present.

Of course the RNSE then displays both front and rear sensors, but because the 8Z0 module is rear only that looks incorrect on the RNSE display. So there's a custom mod to the firmware which, if you send a special sensor data packet for the front sensors, will cause the firmware to not display the graphics for them.

So I would think a similar Arduino hack should be possible for the 8J if it has a 8P0-919-283 fitted. But problem is that the 8J modules will be diagnostics over CAN only (there is no K-Line diagnostics on later Audi models). So the Arduino sketch would need rewriting to do diagnostics over CAN to get the necessary sensor data.

Read about it on the Arduino project page.

As for the 8P0-919-475 module, I didn't realise that had a rear only mode? Isn't this the correct module for OPS anyway? So it just fails to work for OPS if front sensors are missing? That's possibly a separate problem.

What is needed is a car to diagnose on so we can sniff the CAN and work out what is going on. It's possible that the data send over CAN is already present with this module, just the RNSE is ignoring it because it is missing front sensors as the RNSE firmware just wasn't designed to work that way from factory. It's also possible the module just doesn't output anything on CAN in this configuration. In which case, like the A2, it's not fixable in firmware and requires an Arduino assist.

As far as I know mtv6 never sniffed the CAN to to work out what was being sent, and what might be missing, and just went the whole hog and installed the front sensors.

I can walk you through building an Arduino CAN sniffer if you are prepared to help. It's not nearly as difficult as it seems. £15 or so worth of parts of eBay and some free software and a bit of wiring up. Arduino is designed to be largely plug and play.

Once we understand why it doesn't work in rear only configuration we can probably concoct a fix. Either another slightly different Arduino assist, or more ideally a fix to the firmware.


----------



## meteor (Nov 4, 2012)

Pcbbc - a question on the SD-Card Map - In the FAQ you tell to place the supplied licence.key file into the root directory of the SD card in slot 1. Can I use the same slot 1 memory card (even the same partition?) for music files also?

BR, meteor


----------



## Llewkcalb (Jul 15, 2019)

Thanks. I think i understand now.

I have UNO's and familiar with Arduino just not the CAN element.

If you let me know which shield is the preferred one (there are quite alot that look similar) I'll order and get the data.

Steve


----------



## MT-V6 (Jan 11, 2015)

Yes you are right, I just fitted the front. Bear in mind there are multiple 47t modules, some are rear only, and some.are front and rear. I also think only some.of the front and rear support OPS but not sure on that.

Many people have tried to get rear only working without success, even by using the front and rear module with no fronts connected

I'd be interested to follow if it can be done and also interested in any Arduino projects as I am get to try any out


----------



## pcbbc (Sep 4, 2009)

meteor said:


> Pcbbc - a question on the SD-Card Map - In the FAQ you tell to place the supplied licence.key file into the root directory of the SD card in slot 1. Can I use the same slot 1 memory card (even the same partition?) for music files also?
> BR, meteor


MP3 music may be placed on, and played from, the FAT32 partitions on either card. Playing MP3 from the card in slot 2 does NOT affect the ability to also read maps from the special map partition on the same card.
Maps card however MUST be in slot 2 to be recognised for maps.
Licence key can be placed on either card, but probably best placed on all cards. If at all possible it should definately be on the card in slot 1 so it is present when the maps card is inserted.
Presense of a licence key file does not affect in any way the ability to use the same card for MP3s or maps.


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> I have UNO's and familiar with Arduino just not the CAN element.


That's great...

I use this module. There are quire a few clones around, and have sourced various versions from UK sellers and also the above China based seller (cheaper, but you'll wait longer!).

Here's a CAN sniffing sketch for use with UNO and the above module...

```
#include <CAN.h>

char hexascii[] = "0123456789ABCDEF";

void setup()
{
  Serial.begin(115200);
  while (!Serial);
  Serial.println("CANBUS Sniffer");

  if (!CAN.begin(100E3))
  {
    Serial.println("Starting CAN failed!");
    while (1);
  }

  CAN.onReceive(onReceive);
}

void loop()
{
  //Do nothing
}

void onReceive(int packetSize)
{
  uint8_t packet[8];
  uint8_t len = 0;

  uint16_t id = CAN.packetId();
  while (CAN.available())
  {
    packet[len++] = CAN.read();
  }

  if (id == 0x497 || id == 0x6DA || id == 0x67A)
  {
    Serial.print(id, HEX);
    Serial.write(':');
    for (uint8_t i = 0; i < len; i++)
    {
      uint8_t b = packet[i];
      Serial.write(' ');
      Serial.write(hexascii[b >> 4]);
      Serial.write(hexascii[b & 0xF]);
    }    
    Serial.println();
  }
}
```
It filters only the OPS messages.
It's set at 100kbps which is the bus speed of the infotainment CAN.
Also the infotainment CAN does not expect termination. You'll need to cut a pad track on the shield to remove the built in termination resistor.
If you're sniffing the drivetrain CAN you'll need to change the speed to 500kbs (I think).
Drivetrain CAN does require termination, although you'll get away without it on the sheild as the bus in the car has it's own termination.


----------



## Major_B (Dec 15, 2020)

I definitely would like to do this. Happy to send a DVD-R and wonga in return for some fairly idiot-proof instructions.


----------



## pcbbc (Sep 4, 2009)

Major_B said:


> I definitely would like to do this. Happy to send a DVD-R and wonga in return for some fairly idiot-proof instructions.


Start by getting the beta firmware on your RNS-E...

1. Download the firmware from here (December 2020 Beta).
2. Unzip and burn the enclosed ISO to a CD (or DVD-RW / DVD-R if you must).
3. Insert disk into your RNS-E - Wait for the update to complete.


----------



## Llewkcalb (Jul 15, 2019)

pcbbc

I have managed to get a can bus adaptor (In fact 5 for £10.99, but will use others at college so not wasted)

https://www.amazon.co.uk/gp/product/B081W7BPB2/

For anyone else trying the cheap SPI TJA boards ensure you set the clock freq to 8Mhz, had me stumped for a bit, even resorted to dragging scope out of retirement.

Back to job.....

I connected to the infotainment bus at the gateway.

Enabled ops in the parking module. (note you needed security access to do this)
Enabled ops in the RNSE.
Instruments stopped showing park settings so it looks like RNSE now has settings duty.

recorded 2 tests
test 1 - in park - ign on - parked against a wall
View attachment ignON inPARK against WALL.csv

test 2 - in reverse - ign on - parked against a wall.
View attachment ignON inReverse against WALL.csv

i will perform more tests at other distances if you need them.

Steve


----------



## pcbbc (Sep 4, 2009)

This is great thanks,

This...

```
6DA: 42 93 0E 0E 1F 23
```
...is the proximity data from the rear 4 sensors.

I'd expect it to be interleved with front sensor data...

```
6DA: 42 92 FF FF FF FF
```
..but as you don't have front sensors present/coded that probably explains their absense.

The RNS-E checks the incoming data quite robustly for several different packet types and their contents, and doesn't display anything unless it recieves everything correctly. I'm fairly sure it requires both rear and *front* data to be received. That probably explains why having rears only doesn't display anything. The system was never designed/spec-ed/tested to be rear only, so it doesn't expect to be missing front data and treats that as an error.

I can probably fix that very easily.

However also missing from your trace is the whole communication setup pre-amble (I've removed the 0x497 messages which are just status and not important to the protocol per se). Something like...

```
13:39:47.089 -> CANBUS Sniffer
13:39:50.131 -> 67A: 12 82
13:39:50.365 -> 6DA: 02 82 03 00 0A 00 03 00
13:39:50.412 -> 67A: 12 82
13:39:50.412 -> 6DA: 42 82 03 00 0A 00 03 00
13:39:50.412 -> 67A: 12 81
13:39:50.506 -> 6DA: 80 24 42 81 03 00 0A 00
13:39:50.506 -> 6DA: C0 03 00 38 03 FB 80 00
13:39:50.599 -> 6DA: C1 00 00 00 14 1F 03 03
13:39:50.646 -> 6DA: C2 00 06 04 04 06 FF FF
13:39:50.740 -> 6DA: C3 FF FF FF FF FF FF 00
13:39:50.833 -> 6DA: C4 00 00 01 00
13:39:52.505 -> 6DA: 32 82 03 00 0A 00 03 00
13:39:54.517 -> 6DA: 32 83 38 03 FB 80 00 00
13:39:55.734 -> 6DA: 42 96 01
13:39:55.734 -> 6DA: 42 94 FF 01
13:39:55.781 -> 6DA: 42 93 FF FF FF FF
13:39:55.827 -> 6DA: 42 92 FF FF FF FF
13:39:55.827 -> 67A: 22 94 01 01
13:39:55.921 -> 6DA: 42 94 01 01
13:39:55.921 -> 6DA: 42 93 FF FF FF FF
13:39:56.015 -> 6DA: 42 92 FF FF FF FF
```
Thereafter a trace will continue with 6DA: 42 93 ... / 6DA: 42 92 ... messages until such time as the system is disenguaged.

Are you able to try and capture the pre-amble please? Perhaps it only occurs at ignition on?

Then I can validate which bits are missing/different for a rear only system and patch up the RNS-E code so it is less fussy.

Thanks, Stuart.


----------



## Llewkcalb (Jul 15, 2019)

pcbbc

Here are two more captures.

Sequence of capture
1- car off - bus sniffer running
2- ign on
3- from park to reverse
4- from reverse to park
5-ign off
(while still parked close up to a wall)

Some of the start data maybe getting missed as the ignition on triggers the bus to start.

View attachment ignOFF ignOn Reverse Park ignOFF - Recording 1.csv


View attachment ignOFF ignOn Reverse Park ignOFF - Recording 2.csv


Steve


----------



## TonyZed (Jun 14, 2005)

This thread lost me at "I'm proud to announce....." :lol: :lol:


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> Here are two more captures.


Thanks Steve, much better.

That trace starts with...

```
67A: 12 82			
6DA: 42 82 03 00 0A 00 03 00			
67A: 12 81
```
....which was missing from the earlier ones.

Which roughly translate as...
RNS-E -> OPS: Are you there?
OPS -> RNS-E: Yes + some fixed version/identification data	
RNS-E -> OPS: OK, received. I'm good with that. Go ahead...

It looks like all the rest of the data will checkout as well, which is various stuff about current settings for things like volume and frequency of the beeps. Except there will be some missing stuff relating to the front sensors that the RNSE expects but that obviously a rear only unit doesn't send.

I don't think this will be hard to fix in firmware alone. Give me a day or two...

Stuart.


----------



## MT-V6 (Jan 11, 2015)

Interesting stuff, but out of interest why are you recording the infotainment canbus? Clearly you are getting messages so it can't be wrong, but regardless my front+rear OPS module is only connected to the powertrain canbus


----------



## Llewkcalb (Jul 15, 2019)

MTV6

I was looking for the messages going to the RNSE, these are via the infotainment bus.

I guess it could have been monitored from the messages from the powertrain bus.

Going with pcbbc's guidance on terminating buses too, the infotainment bus didn't need me to worry about terminators.

Steve


----------



## MT-V6 (Jan 11, 2015)

Ah I see. I need to learn more about canbus. Does the gateway copy these messages across from powertrain to infotainment?


----------



## pcbbc (Sep 4, 2009)

MT-V6 said:


> Ah I see. I need to learn more about canbus. Does the gateway copy these messages across from powertrain to infotainment?


Yes, the gateway acts as a bridge and copies the OPS messages (and others) between buses. So you can sniff either entertainment or drivetrain if you want to see the OPS messages.

That's not the case for all CAN messages though. The gateway only copies things that it has been told about and that have been deemed necessary (because something on the other bus is interested in them).


----------



## pcbbc (Sep 4, 2009)

Okay, @MT-V6 and @Llewkcalb.

The reason why the OPS doesn't display with a rear-only coded unit is the RNS-E is expecting two packet types via the CAN OPS protocol:
a) 0x10 = Front frequency/volume settings
b) 0x12 = Front sensor data
Obviously a rear only unit doesn't provide these, and so the RNS-E (which was only programmed to expect a front+rear coded module) thinks there is missing data, and therefore refuses to display anything.

Correcting for this in the firmware is relatively easy (by making these packet types optional) but gives me this...









When I was obviously expecting this...









...which is what I get when I playback a CAN trace from a correctly coded front+rear module.

Is this just incorrect coding by Llewkcalb? It looks like the module is telling the RNS-E to start in camera/park assist mode?

Need to know if this is something else that needs "fixing" in the firmware, or if it's just down to pure coding.

Please remember that I've never actually coded or fitted an 8P0-919-475, so I have no idea what coding is required or what options are available. My guess is MT-V6 is best placed to provide input on that.

Edit: For me screen shots of the VCDS coding and options would be very helpful to aid my understanding.

Thanks guys, Stuart.


----------



## Llewkcalb (Jul 15, 2019)

Hi

Thanks for looking at it further.

I'll screenshot the modules coding today but there isn't much to get wrong.

As I said too, when i enabled ops it took away the options automatically from the instruments. Which makes me think it's now looking to the RNse for settings.

Does the RNse need send anything more back to the park module?

Would it worth trying the new firmware on the car?

Steve


----------



## MT-V6 (Jan 11, 2015)

I'd need more help in setting up canbus tracing as above, but I am happy to record from my car


----------



## MT-V6 (Jan 11, 2015)

FYI with OPS enabled the PDC settings move to the RNSE rather than the DIS


----------



## Llewkcalb (Jul 15, 2019)

MT-V6 said:


> FYI with OPS enabled the PDC settings move to the RNSE rather than the DIS


Yes i noticed that when i enabled ops.


----------



## Llewkcalb (Jul 15, 2019)

MT-V6 said:


> I'd need more help in setting up canbus tracing as above, but I am happy to record from my car


Do you have any Arduino experience? I can show you what I did.


----------



## Llewkcalb (Jul 15, 2019)

pcbbc said:


> Okay, @MT-V6 and @Llewkcalb.
> 
> Is this just incorrect coding by Llewkcalb? It looks like the module is telling the RNS-E to start in camera/park assist mode?
> 
> ...




















The other bytes are "car type" and "LHD/RHD", funnily I cant set the car to RHD and has always been coded as LHD.

Steve


----------



## pcbbc (Sep 4, 2009)

Okay, thanks for this. As you say, not much to get wrong with regard coding.

I guess the issue is at the RNSE end. Some further checks later on with regard to the data sent. The first step, as I said, is to validate all packet types were received successfully. I'll do some more digging.

For now no use installing the current firmware. That firmware is still expecting all the packet types for a front+rear coded module, so will display nothing unless they are all received.

When I did the patches to support rear only mode with an Arduino for the A2 I had no idea what a factory fit rear only module would send over CAN. So to signal a rear only unit I had the Arduino send DE AD BE EF as the front sensor values, which seemed a very unlikely set of values to receive in real life.


----------



## pcbbc (Sep 4, 2009)

For those still following along, some notes on the CAN format. It's somewhat complicated to allow for messages longer than 8 bytes, and is a shared protocol between OPS, the official Audi reversing camera, and AMI.


```
First 2 bytes:
0---------------	Basic packet flag (6 bytes or less)
0xxx------------	Some kind of type?
0---xxxxxx------	Device: 0A=OPS, 0B=Reverse Camera, 2F=AMI
0---------xxxxxx	Packet ID: Device dependent
Followed by up to 6 bytes of packet data

Or:
1---------------	Extended packet flag (more than 6 bytes)
10--------------	Start packet indicator
10xx------------	Pipe id? For 4 separate pipes
10--xxxxxxxxxxxx	Extended packet data length
Followed by 2 bytes as per basic packet (type/device/id)
Followed by first 4 bytes of packet data

Followed by continuation CAN packets:
11------			Continuation packet indicator
11xx----			Matches pipe ID of  first packet
11--xxxx			Sequence counter
```
Ok, so now we have that straight, for a front+rear module we get the following data over CAN...

```
Basic packets:
6DA: 02 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
6DA: 42 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes

Extended packet:
6DA: 80 24 42 81 03 00 0A 00
6DA: C0 03 00 38 03 FB 80 00
6DA: C1 00 00 00 14 1F 03 03
6DA: C2 00 06 04 04 06 FF FF
6DA: C3 FF FF FF FF FF FF 00
6DA: C4 00 00 01 00

The above extended packet gets decoded by the 03 flags packet to the following packets:
								02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
								03 = 38 03 FB 80 00 00 00 00	Flags - indicate supplied packet IDs
								04 = 14							Some kind of timeout value
								0E = 1F 03 03					First byte must have 4 low bits set to display OPS
																Second byte flags for front vol/freq supported
																Third byte flags for rear vol/freq supported
								0F = 00							00=vol/freq adjustment enabled
								10 = 06 04						Front vol/freq setting
								11 = 04 06						Rear vol/freq setting
								14 = 00 00						OPS off?
								16 = 00							00=Don't display OPS
								17 = 01							Unknown

Basic packets:
6DA: 32 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
6DA: 32 83 38 03 FB 80 00 00	03 = 38 03 FB 80 00 00			Seems to be a duplicate of extended packet flags?
6DA: 42 96 01					16 = 01							01=Display OPS			
6DA: 42 94 FF 01				14 = FF 01						OPS on?
6DA: 42 93 FF FF FF FF			13 = FF FF FF FF				Rear sensors (L - LC - RC - R)
6DA: 42 92 FF FF FF FF			12 = FF FF FF FF				Front sensors (L - LC - RC - R)
```
And now looking at the rear only data as kindly provided by Llewkcalb:

```
Basic packets:
6DA: 02 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
6DA: 42 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes

Extended packets:
6DA: 80 1D 42 81 03 00 0A 00
6DA: C0 03 00 38 03 5B 00 00
6DA: C1 00 00 00 14 0A 00 03
6DA: C2 00 04 03 FF FF FF FF
6DA: C3 00 00 00 01

The above extended packet gets decoded by the 03 flags packet to the following packets:
								02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
								03 = 38 03 5B 00 00 00 00 00	Flags - indicate supplied packet IDs
								04 = 14							Some kind of timeout value
								0E = 0A 00 03					First byte must have 4 low bits set to display OPS
																Second byte flags for front vol/freq supported
																Third byte flags for rear vol/freq supported
								0F = 00							00=vol/freq adjustment enabled
								11 = 04 03						Rear vol/freq setting
								14 = 00 00						OPS off?
								16 = 00							00=Don't display OPS
								17 = 01							Unknown

Basic packets:
6DA: 32 82 03 00 0A 00 03 00	02 = 03 00 0A 00 03 00			Version?  RNS-E checks for these exact bytes
6DA: 32 83 38 03 5B 00 00 00	03 = 38 03 5B 00 00 00			Seems to be a duplicate of extended packet flags?
6DA: 32 84 14					04 = 14							Some kind of timeout value
6DA: 32 8E 0A 00 03				0E = 0A 00 03					Seems to be a duplicate of extended packet?
6DA: 32 8F 00					0F = 00							00=vol/freq adjustment enabled
6DA: 42 96 01					16 = 00							00=Don't display OPS
6DA: 42 94 FF 01				14 = FF 01						OPS on?							
6DA: 42 93 FF FF FF FF			13 = FF FF FF FF				Rear sensors (L - LC - RC - R)
```
Things to notice:
1. Packet type 0x10 for front vol/freq setting is not sent. The RNS-E expects this packet type or else nothing is displayed.
2. Packet type 0x12 for front sensor data is not sent. The RNS-E expects this packet type or else nothing is displayed.
3. Packet type 0x0E starts with byte 0x0A instead of 0x1F. This is what is causing the park assist mode to display, instead of OPS. The bottom 4 bits need to be set for OPS to display.

Edit: Some more details on the decoding of the extended packet with packet ID 01
This seems to consist of a mandatory type 02 packet with the fixed data: 03 00 0A 00 03 00
Followed by a mandatory type 03 packet: 38 03 FB 80 00 00 00 00 or 38 03 5B 00 00 00 00 00 in the examples above
The data in the 03 packet is a sequence of bit flags with each flag indicating which of the other packet IDs are included in the remaining data (actually there are flags for the supposedly mandatory 02 03 packet IDs as well, but it's not clear how they could be used due to the flags needing to exist at a defined location in the extended packet). So...
3803FB80... = 02 03 04 0E 0F 10 11 12 13 14 16 17 18
38035B00... = 02 03 04 0E 0F 11 13 14 16 17
Note that for some reason some packet IDs are supplied (12, 13 & 18) but just skipped by the firmware. Instead the firmware waits for the basic packet format of these IDs to provide the data.

So I can fix detection of the rear only module CAN data in the next firmware. The only think I am not certain about is changing the handling of the 0x0E packet first byte. If I make 0x0A also display the OPS (instead of park assist mode) like the 0x1F value does, what knock on effect might this have on officially supported configurations?

I suppose the only way to find out is suck it and see...

Stuart.


----------



## Llewkcalb (Jul 15, 2019)

Kudos again for fighting on.

Would you be willing to fork your firmware to a second variant? (For genuine OPS users like MTV6 and modified users like myself)
I'm be happy to pay for it under your license version idea.

Another brain wave I had today was to utilise the CANBUS adaptors i got cheap and make a gateway to the RNSE, using two CANBUS units; break the data and then pass on etc with modified bytes.

You also peaked my interest here when you said AMI and CANBUS, do you know what messages the AMI and RNSE share ( I also have the AMI but dont use it)?

Steve


----------



## pcbbc (Sep 4, 2009)

No problem.

I'm trying my real best to avoid separate firmwares. That way leads to a completely unsupportable and unmaintainable product for all involved.

Not sure you can easily fix this with a third party module unless you completely isolates the parking module from the RNSE. In which case sure, you can modify the packets as they pass through the device and fake the CAN data to resemble a full front+rear system. I don't think that should be necessary though.

To me it seems like the stock firmware is somewhat "unbaked". If I send 1F 00 03 for the 0E packet, and get the firmware to ignore the missing 10 and 12 packets, the RNSE works - bar displaying the front sensor graphics when they aren't available/needed.

It's interesting though that the settings page correctly displays vol/freq adjustment for *only* the rears - so firmware already pays attention to other (assumed) aspects of the 0E packet. At least the original RNSE developers got that part right. I suspect the firmware was coded to a spec provided by Audi, but at the end of the day only tested and debugged against a front+rear configured system.

Let me fix the firmware up as best I can, and we'll see if we get any complaints (hopefully none!) from people with ops+cam fitted. Hopefully MT-V6, who I know has such a system fitted, can provide us some feedback on that aspect.

What were the original factory fit options?
Plain PDC to rear only (never with OPS)
OPS *always* front and rear (in conjunction with 2010+ 193 PU RNS-E)
CAM also an option (in addition to front and rear OPS) on the R8 42

Is that our lot?


----------



## MT-V6 (Jan 11, 2015)

pcbbc said:


> What were the original factory fit options?
> Plain PDC to rear only (never with OPS)
> OPS *always* front and rear (in conjunction with 2010+ 193 PU RNS-E)
> CAM also an option (in addition to front and rear OPS) on the R8 42
> ...


I think that's almost the lot. I think front and rear was available without OPS too. Also front and rear is an A3 8P/R8 42 option and was never available on the TT 8J


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> The other bytes are "car type" and "LHD/RHD", funnily I cant set the car to RHD and has always been coded as LHD.


Sorry - Are you sure there aren't any adaptation channel settings (not long coding) relevant to park assist?

I'm still very concerned about the interpretation of the 0E packet ID by the RNS-E.

A correctly coded front+rear unit that displays OPS with the stock firmware will send:
0E = 1F 03 03

Meanwhile your rear only module is sending:
0E = 0A 00 03

The RNS-E is expecting the low 4 bits of the first byte to be all set (?F) to enter OPS display mode, otherwise it selects the park assist display as in the screen shots I posted earlier.

I know why the 00 is sent instead of 03. Those are flags to indicate the availability of the front freq/vol settings, and are already being correctly interpreted by the stock RNS-E firmware.

















It really doesn't feel at all right changing the meaning of the first byte, since the interpretation of the other data conveyed by this packet is already 100% correct.

Perhaps maybe the 4 bits also indicate availability of settings?
F=0b1111 (4 bits set for 4 settings)
A=0b1010 (2 bits set for 2 settings)
Which might make some sense - but why duplicate the functionality of the other 2 bytes? And then what is the correct way to indicate park assist mode?

Normally I'd open the lbl file in VCDS and check the coding options for myself. Unfortunately the 8P0-919-475 modules are encrypted in clb files, so can't be inspected.


----------



## Llewkcalb (Jul 15, 2019)

pcbbc said:


> Sorry - Are you sure there aren't any adaptation channel settings (not long coding) relevant to park assist?


Just these, but you already accounted for them.


----------



## Llewkcalb (Jul 15, 2019)

Pcbbc

Another thought, when MTV6 fitted ops a switch was added too, will this switch be in the message?

Steve


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> Pcbbc
> Another thought, when MTV6 fitted ops a switch was added too, will this switch be in the message?
> Steve


Not unless the switch was connected directly to the PDC/OPS module.
No OEM modules ever produce messages on the same CANBUS ID as other modules.

The other option is the switch sends a message (on a different channel) to the OPS/PDC module, and then the module relays that to the RNSE on the CABUS channels we know about.


----------



## Llewkcalb (Jul 15, 2019)

Its my understanding that the front rear ops system has the switch wired directly to it.

Steve


----------



## MT-V6 (Jan 11, 2015)

The PDC button is wired directly to the PDC module. 1 signal wire and 1 for the LED. It uses a common earth for the existing buttons


----------



## pcbbc (Sep 4, 2009)

MT-V6 said:


> The PDC button is wired directly to the PDC module. 1 signal wire and 1 for the LED. It uses a common earth for the existing buttons


That's interesting, but the button controls the beeping (or not) of the front sensors does it not? - Or am I mistaken?

What about the park assist? Although I know you (MT-V6) don't have park assist... But that's what the icon in the top right of my previous post represents is it not?

Although did any RNSE equipped model support park assist? I'm not sure, I think NOT....

I'm wondering how the PDC module indicates the state of the PDC button to the RNS-E, or maybe it doesn't need to?
If it's inactive it just sends FF data for the front sensors, and doesn't generate any tones for it?
It doesn't display a different graphic, does it?


----------



## MT-V6 (Jan 11, 2015)

pcbbc said:


> That's interesting, but the button controls the beeping (or not) of the front sensors does it not? - Or am I mistaken?
> 
> What about the park assist? Although I know you (MT-V6) don't have park assist... But that's what the icon in the top right of my previous post represents is it not?
> 
> ...


The button enables the OPS of all sensors (and camera) at speeds below ~10mph. Reverse gear will automatically enable it too, so the button is mostly for use when driving forward into a space. It will also turn off the beeping/OPS.

Park assist is something I have briefly looked into but not properly. It does use a variation of the PCD module but with support for 10 sensors (6 front, 4 rear), and it also has a separate additional button (but also uses coding on the instrument cluster that doesn't seem to be available on the TT).

The top right icon just changes the overlay over the camera image, so is separate to OPS. So I would say your screenshot shows the RNSE reverse camera screen but without OPS overlay? But also without the "Settings" or "Graphic" text for the bottom soft keys. See the bottom of the first post here for an example https://www.ttforum.co.uk/forum/viewtop ... &t=1921981


----------



## pcbbc (Sep 4, 2009)

Hi Llewkcalb,

I have an alpha version, if you'd like to try it? Just the same as the current Beta, but with the fixes for the detection of a reverse only 8P0 OPS/PDC module.

Tested on my 193, and seems to be working when I fire the CANBUS traces at it that you kindly captured for me.

I'll send you a link in a PM.

Stuart.


----------



## Llewkcalb (Jul 15, 2019)

Success!!!



















Super pleased with this mod. As you can see i park quite near the back wall of the garage.

Pcbbc, you have resurrected the RNSE


----------



## pcbbc (Sep 4, 2009)

Llewkcalb said:


> you have resurrected the RNSE


LOL.

No, thanks for *your* help. This wouldn't have been possible without you supplying the logs in the first place. People sometime assume I either know everything, or have access to an complete collection of Audi vehicles to test on. Which simply isn't the case....

This mod will go in the next beta, whenever that's ready. I want to get UK motorways in blue and installable language packs in the next release. Plus I still have the US firmware which needs all the current beta features testing.


----------



## MT-V6 (Jan 11, 2015)

Very good!



pcbbc said:


> I want to get UK motorways in blue


Looking forward to this


----------



## Jezzie (May 24, 2020)

MT-V6 said:


> Very good!
> 
> 
> 
> ...


Nah - no motorways in Dorset, didn't even know they weren't blue already!


----------



## MT-V6 (Jan 11, 2015)

I have a test version from pcbbc on mine from a while ago when he was testing the canbus reverse camera mod. A little detail that I like and have pestered him to add to the 'official' version


----------



## MT-V6 (Jan 11, 2015)

Finally got round to updating my RNSE with the beta 0280 firmware today, I'll let you know how I get on with it

Something I have noticed that you might not be aware of, is that with the SD maps, it doesn't display the map version on the version screen. Doesn't really matter but could possibly be helpful if you have multiple SD cards if on a roadtrip across Europe for example?


----------



## Jezzie (May 24, 2020)

Great to see Mat Armstrong's bought himself a Lamborghini - with an RNS-E !!


----------



## ab54666 (Nov 18, 2019)

Jezzie said:


> Great to see Mat Armstrong's bought himself a Lamborghini - with an RNS-E !!


An older unit at that! Always like the Gallardo as a sensible priced supercar.


----------



## pcbbc (Sep 4, 2009)

MT-V6 said:


> Something I have noticed that you might not be aware of, is that with the SD maps, it doesn't display the map version on the version screen. Doesn't really matter but could possibly be helpful if you have multiple SD cards if on a roadtrip across Europe for example?


Do you still have the update CD/DVD in the DVD drive by any chance?
CAR -> Version -> Map displays correctly for me as long as I don't have an optical disk inserted.
If you want to check the SD map version with a disk inserted you can always select NAV -> SETUP -> Version Information.


----------



## MT-V6 (Jan 11, 2015)

I might have, not sure actually... I did take it out and put a music cd in there just to test navigation still worked and it did  will check that out though


----------



## pcbbc (Sep 4, 2009)

MT-V6 said:


> I might have, not sure actually... I did take it out and put a music cd in there just to test navigation still worked and it did  will check that out though


Yes, any media in the drive (other than a map disk) will cause the map version to be blank.
Probably it should get the version from wherever the map setup gets its data, but it doesn't seem to have been coded that way.


----------



## nick2000 (Oct 14, 2018)

This is so awesome to have an upgrade on the RNSE ! 

Big THANK YOU for your work to enable this.


----------



## TT'sRevenge (Feb 28, 2021)

Quick question installing this (yeah I never did this despite purchasing over a year ago lol). I noticed the instructions say, "DVD-R or DVD-RW media are not required for firmware updates. Please use a CD. " Does one have to use a CD-R? It's a little vague as it doesn't say you _can't_ use a DVD, but seems to encourage using a CD instead?

I have found exactly one blank CD-R which is probably some 25+ years old I'd imagine. OTOH I have like 50+ blank DVDs on hand, though granted those must be like 20 years old themselves lol. I swear I had more CD-Rs somewhere but either I don't or just can't find 'em. Wow seems like ancient history to burn a disc, eh? 

I guess I can write to this one CD-R and verify--make sure it works. For any future updates though, would I be good to use a DVD?

Also I can go straight from the factory fw to the current "Elm" version, correct?

Edit: Nm got this all sorted out--used that CD-R and it worked w/o issues. However will I need more CD-Rs if there are any future updates or can a DVD+R be used?


----------



## TT'sRevenge (Feb 28, 2021)

Regarding enabling OPS...

I have the exact same Park Assist module at address 10:


Llewkcalb said:


> View attachment 453705
> 
> View attachment 453707
> 
> ...


All the numbers/versions are the same...
Part No SW: 8P0 919 475 M HW: 8P0 919 475 M
Component: PARKHILFE 4K H01 0140 
Revision: 11001001 
Coding: 00010B
Shop #: WSC 01236 758 00200

However my stock coding is 00010B as shown and if I try to change it to 10010B (i.e. checking Bit 4 in Byte 0), when I try to save the coding it gives me an error--that it's out of range. Is there something that has to be done before changing the coding in this module?


----------



## ab54666 (Nov 18, 2019)

I'd love to do some of these updates but sadly don't have a PC with a CD/DVD drive!


----------



## TT'sRevenge (Feb 28, 2021)

TT'sRevenge said:


> Regarding enabling OPS...
> 
> I have the exact same Park Assist module at address 10:
> 
> ...


Well looks like my problem was actually just security access. Tried again today and after putting in the security access, it worked. After that I added +2 to the 3rd digit in RNS-E coding and voila, OPS working!  

Only thing is I'm not sure how to get to the parking volume/tone settings from the menus--can't seem to find it. However if I engage reverse and the OPS screen comes up, then I can hit settings there to adjust. I mean not like it's something I ever adjust but just wondering if there's a way there without having it in OPS mode (i.e. being in reverse)?


----------



## MT-V6 (Jan 11, 2015)

Don't think so. Normally if you have 8 sensor OPS you'd have a button on the centre console. You could give that a try and see if it works on the 4 sensor module. See my guide


----------



## TT'sRevenge (Feb 28, 2021)

MT-V6 said:


> Don't think so. Normally if you have 8 sensor OPS you'd have a button on the centre console. You could give that a try and see if it works on the 4 sensor module. See my guide


Ah I see, so basically just have to put it in R and then hit settings, if ever needed. Not a big deal. I've only ever adjusted those things once anyway, when I got the car.

What I find interesting though is how many things are possible they just didn't allow/give you/make possible as you buy the car. If pcbbc and Llewkcalb could figure this out between them (thanks guys, BTW!  ) it's puzzling how Audi couldn't implement this. Like why no OPS on just the rear sensors? The front sensors weren't even an option here so why didn't they make the OPS work with the 4-sensor cars? I mean it's not like it was a selling point to say "hey if you get the front and rear parking sonar, you get OPS too"...you couldn't even get that (here) so not sure what they were thinking. 

RNS-E system seems so unpolished/unfinished like it was designed for/capable of so much more than they bothered to make it do. Thankfully @pcbbc to the rescue!🙂


----------



## MT-V6 (Jan 11, 2015)

It's all just A3 8P parts sharing I think, same even with the gen 1 R8. All comes down to money I assume, can't have been worth the development cost vs number of TT buyers willing to pay extra for it


----------



## pcbbc (Sep 4, 2009)

From the look of the code, and knowing a bit about how software is developed, it wouldn't have been a conscious decision NOT to have a 4 sensor rear only mode.

Audi would have requested the addition of the OPS system from the software developers at Aisin (the manufacturers of the RNSE units). Part of that specification would have said we want the unit to work with this particular set of PDC modules, which at the time were only 8 sensor modules.

Now that spec may not even have included the details for 4 sensor modules, but even if it did the people back at Audi would have had no cause to test against a 4 sensor system unless the requirements said it was a specific build option in production vehicles.

if it later became a requirement for OPS to work with rear only builds, then that configuration would have been tested, the firmware found not to work correctly, and a fix requested from Aisin. Between them they’d have thrashed it out if that was Audi’s fault (not requested in spec) or Aisin’s fault (not reading spec and testing correctly).

However that situation never happened, so we have a final firmware with broken implementation of rear only 4 sensor mode.

FYI the Audi policy of NOT providing parking radar view (OPS) on rear only systems continues to this day. The MK3 with rear only sensors doesn’t have the OPS enabled as a factory option, and you have to pay for the front+rear sensor option to officially get OPS. Luckily, either through luck or judgement, the rear only mode actually works if you simply enable it via coding on the MK3.

TL;DR This isn’t a case of Audi specifically disabling rear only as a feature. It’s the fact that they never wanted to provided it, so it was either never specified, or never tested.


----------



## TT'sRevenge (Feb 28, 2021)

Oh I see, thanks for the detailed explanation! Makes sense and really appreciate you got this figured out and implemented for the rear-only module 

Anyway a new general RNS-E question...

What's the cheapest way to get video into the unit? It seems it uses RGBS input but it seems rather impossible to find a generic composite (CVBS) or HDMI to RGBS adapter or module. I see you can use Kufatec's IMA but even the basic plus the cable is going to be over $200+. Seems like a ton of money just to get video into the unit 

I see a bunch of RNS-5xx (VW) units which are meant for reversing cameras that do convert composite to RGBS. Those go for around $50, but I'm not sure if those will work on the RNS-E or if they could be repinned/rewired to work?

Also the firmware allows VIM, but does it allow the video input to be selected when appropriate changes are made with VCDS? Or does one still need something like the Kufatec to make the TV/video input selectable to begin with? 

I actually was able to source an RPi 3b for a decent price (nearly impossible to do these days with the "shortages") so I was going to attempt the Android Auto project but then if it's going to cost like $250 just to get video into the RNS, I might abandon this project.


----------



## MT-V6 (Jan 11, 2015)

You will need one of those devices, cheaper ones are available I think but might not be so reliable? Not only do they convert the video signal but they mock a TV module on the canbus which allows the input to be usable on the RNSE

I was going to give the Pi project a go too but mine is too old so also need to get hold of one


----------



## TT'sRevenge (Feb 28, 2021)

MT-V6 said:


> You will need one of those devices, cheaper ones are available I think but might not be so reliable? Not only do they convert the video signal but they mock a TV module on the canbus which allows the input to be usable on the RNSE


Darn I was hoping the fw enabled the video/TV mode without having to have an actual module on the bus. If that's not possible it seems like it will add up to way too much money. Wish I'd known this before buying the RPi lol.

This is pretty much what a IMA "Basic Plus"...plus cable costs:








Genuine Kufatec Multimedia Adapter DVD DVB-T for Navi Radio Audi RNS-E RNSE | eBay


Find many great new & used options and get the best deals for Genuine Kufatec Multimedia Adapter DVD DVB-T for Navi Radio Audi RNS-E RNSE at the best online prices at eBay! Free shipping for many products!



www.ebay.ca





After shipping, import fees, that's easily $250 or more CAD. Plus the Pi itself cost me $65 (which is still considerably less than what people are selling them for on the used market), then still need to get the Pi-to-CAN adapter for this project (which looks like it'd cost near to $100 as well) and some other odds and ends. In the end it'll be like $500+ and that's an amount just getting out of control IMO. I'd sooner just replace the head unit with aftermarket at that rate. But not gonna do that either (cause I don't want to spend anything near that), so looks like I'll just get a phone mount from the likes of OE Mounts or Clearmounts. I mean those are expensive for what they are too, but in absolute terms we're talking $50, not $500 lol.



MT-V6 said:


> I was going to give the Pi project a go too but mine is too old so also need to get hold of one


You mean you have the 192 unit I take it? But the guy's project is actually based on the 192 unit--that's what he has too. If you have a video input module already, and can get a Pi for a decent price, then perhaps it's worth it for you to give it a go?


----------



## MT-V6 (Jan 11, 2015)

TT'sRevenge said:


> You mean you have the 192 unit I take it? But the guy's project is actually based on the 192 unit--that's what he has too. If you have a video input module already, and can get a Pi for a decent price, then perhaps it's worth it for you to give it a go?


I have the 193 and the kufatec module but my R8 reverse camera module is taking the only video input on the RNSE, and it's fussy about input switching using a relay. I believe solid state relays might be fine but I have not got the parts to try that yet either


----------



## darrylmg (Oct 16, 2021)

TT'sRevenge said:


> Darn I was hoping the fw enabled the video/TV mode without having to have an actual module on the bus. If that's not possible it seems like it will add up to way too much money. Wish I'd known this before buying the RPi lol.
> 
> This is pretty much what a IMA "Basic Plus"...plus cable costs:
> 
> ...


I went and bought some super cheap RGB converter on aliexpress and the audi 32 pin connector.
Apparently it just needs re-pinning. I'm doing this work this Saturday and will test it on the rns-e before I go the full mile and fit the camera on the boot and feed wiring.
Total cost would be £20 if it works.
As for reliability... well, put it this way, the unit is light as a feather. Can't be much inside it to break except a PCB. I've bought two  🤞 🤞 🤞 🤞


----------



## TT'sRevenge (Feb 28, 2021)

darrylmg said:


> I went and bought some super cheap RGB converter on aliexpress and the audi 32 pin connector.
> Apparently it just needs re-pinning. I'm doing this work this Saturday and will test it on the rns-e before I go the full mile and fit the camera on the boot and feed wiring.
> Total cost would be £20 if it works.
> As for reliability... well, put it this way, the unit is light as a feather. Can't be much inside it to break except a PCB. I've bought two  🤞 🤞 🤞 🤞


Any links to the converter? I can't find much of anything on there.

Also, as mentioned above, even if the converter works to convert to RGBS, wouldn't there be an issue actually activating the TV/video input on the RNS? Or are you just planning to use this as reverse cam only and use the RFSL thing (if you have a unit that has that)?


----------



## pcbbc (Sep 4, 2009)

Here‘s the VW RNS510 converter.

Note that it doesn’t include a CANBUS module to enable the TV input option on the RNSE media source menu. You won’t need this if you just want a reversing camera input, but it is necessary for a dedicated AV input. The alternative for a CarPC setup is to add a CANBUS module to that, then send the required CANBUS messages to simulate the TV module from the PC with appropriate software.

You’ll need to swap the supplied 26 pin VW plug for a 32 pin Audi one. If you don’t already have a plug for your RNSE, an easy way to get one is purchase a MP3 adapter.

No connection with either of the above AliExpress sellers, but I have purchased both of the linked items, received them, and confirmed they work.


----------



## TT'sRevenge (Feb 28, 2021)

pcbbc said:


> Here‘s the VW RNS510 converter.


Yeah those were the type I was looking at--around $50 but the problem is this part...



pcbbc said:


> Note that it doesn’t include a CANBUS module to enable the TV input option on the RNSE media source menu.





pcbbc said:


> You won’t need this if you just want a reversing camera input, but it is necessary for a dedicated AV input. The alternative for a CarPC setup is to add a CANBUS module to that, then send the required CANBUS messages to simulate the TV module from the PC with appropriate software.


Ah I see yeah that guy that wrote the code for the AA thing he had a 192 unit and used a Kufatec to get video in, so that was definitely not part of the code. I'm no programmer so I'd have no idea where to even start to get that to happen, lol. I don't think that guy would be open to changing or updating the code as he never has and it was basically just a project he did for his own use and posted it online. In fact some people posted his code only works on Pi 3b and earlier and doesn't work on any newer ones, but them's the breaks when you're using someone else's thing and can't do your own tinkering in the code. 

For that reason I went to the trouble of sourcing a 3b exactly; it all seemed like a great idea until I realised the video input cost. At least I'm pulling out now instead of going down the sunk cost route! On the bright side I could reasonably resell the Pi for more money than I paid for it, though I'm probably more inclined to just hang on to it since I might one day do something with it.



pcbbc said:


> You’ll need to swap the supplied 26 pin VW plug for a 32 pin Audi one. If you don’t already have a plug for your RNSE, an easy way to get one is purchase a MP3 adapter.


Heh I was thinking the exact same thing if the connector was needed, but a moot point now given the video input activation thing.


----------



## TT'sRevenge (Feb 28, 2021)

New question about putting maps on SD cards. I'm just trying this now in NavPOInt but it doesn't seem like you're able to put more than one disc on an SD from the program?

For example my mapset (NAR 2017/2018) spans two discs. But how does one get the data from _both_ discs onto a [single] SD card? Or is that not possible? I tried loading one disc and writing the SD card, thinking maybe it's going to ask me for the second one but doesn't do that it just seems to finish the SD card writing from the inserted disc and that's that. When I load up the second disc it just wants to format/write the SD card all over again, presumably with just the data from the second disc...

My disc #1 is like 5.7GiB and disc #2 is around 6.1GiB--both would easily fit on one SD card but not sure if this can be done with NavPOInt? Is it possible to like copy both discs to a directory and then write from there? There seems to be some special SD formatting used so I don't think it's possible to just add files on there, either. Would I need to keep two SD cards, one for each nav disc?

Interestingly discs 1 & 2 have some overlap--Canada, for example, seems to be on both discs but the US states are definitely divided between the two discs depending on region (e.g. midwest, northeast, etc.)


----------



## pcbbc (Sep 4, 2009)

Not possible to merge disks, sorry. Please make separate cards for each disk, and exchange cards in the same way as you’d exchange DVDs.

To do a “merge” you’d need to ”take apart” a couple of ~6GB databases and reassemble. Most importantly with all internal references to data in those databases adjusted to account for the moved/merged data.

Even if you did that (huge amount of work), which technically might be possible with the specification of the KIWI database being largely documented, additionally there’s a size restriction of 4GB for any single file on a DVD. Certainly for the European DVDs (haven’t explicitly checked NA) the combined ALLDATA.KWI (with the majority of the map stuff in it) file will exceed that fundamental limit.

Or you’d need some clunky UI mechanism to select between multiple disks on the same card. That would be possible, but given where I am with UI adjustments (note there are very few of them as a result), and the number of people who actually make cross disk journeys on a regular basis (I’m going to suggest small), I’m going to pass on that for now. Sorry.


----------



## TT'sRevenge (Feb 28, 2021)

Ahhh gotcha, fair enough. I'll put the other disc on another SD- Seems like a waste of SD space to use anything larger than 8GB for these in that case, though of course one can almost not buy SDs that small anymore. I'll see what I have in my collection of old SD cards 

And yeah totally forgot about the DVD file limits, been so long even dealing with DVD/optical writing heh. I guess even when putting on SD the RNS-E is still seeing those maps as an emulated or mounted DVD, the way you have accomplished this?

Totally agree you're very rarely navigating "over two discs" so not really a big deal, I was actually just thinking "if you use a big enough SD it will all fit"--perhaps it can be made clear in the documentation each disc needs to have its own SD  As I said, they actually put all of Canada on both discs it seems, probably because data-wise it takes up about the same amount of space as like 1-2 US states  I only figured that out travelling to the US and being like why isn't this state on this disc when it's right next to me? Put in the other disc and there it was, yet Canada still on that too haha.

Side question: How does the RNS-E even handle routing over two discs anyway? Like even stock, if I planned a destination that required two discs, what would it do? Never tried but seems an interesting question.

Speaking of these KWI maps/data... Since these seems to be some standard format and used by other Aisin nav units, I wonder if it's possible to take newer maps from say a Toyota, etc. that uses them and put together a newer map update for the RNS-E? Or are is there too much customised, Audi/RNS specific, changes or files required to do this?


----------



## Jezzie (May 24, 2020)

You can always fill the SD cards with music files


----------



## TT'sRevenge (Feb 28, 2021)

Jezzie said:


> You can always fill the SD cards with music files


You can, though it does say (in the pcbbc manual) that's not recommended due to possible slowdowns. I'll just stick with #1 slot for music... 

That said I already noticed even inputting an address is snappier with the SD card compared to disc. I didn't think it would speed _that_ up (I thought that was laggy due to the interface) but it seems noticeably improved with maps on SD  Usually there's a somewhat painful delay between each letter, it seems that has been made more quick just by having the maps on SD. Seems the delay is more caused by it trying to lookup within the street/city names within the map data (which takes much longer to access on an optical disc) rather than the interface itself being laggy.


----------



## pcbbc (Sep 4, 2009)

SD cards can be used for additional mp3 music on 193 units. Don’t recommend trying this on 192 units, as bandwidth to card is not sufficient to support both maps and mp3 playback.

Yes, the maps are stored on the card as an ISO file system, in same format as optical media. So in the firmware it is just* a case of redirecting sector reads from the DVD to the SD card.
* For some definition of “just”.

I believe the unit allows you to plan routes across disks, and prompts you to insert the next disk at the border? I think that’s what the manual said? Never tried it though. Sorry!

Russian’s use modified Toyota maps as there was never an official Audi release for Russia. I don’t think their donor system is still produced either. I did get some Toyota maps still in production in some sort of kiwi format, but there are were substantial deviations from the standard. My program that can draw the maps from the RNSE ALLDATA.KWI couldn’t make head nor tail of it. I was hoping it would only need a very few minor changes to make it work, but unfortunately not.

Delays are just to track seek times on optical media. The database format Is optimised as much as possible for linear (as opposed to random) access, but still a few seeks are required to get the next selection of available letters and street/town names. In contrast reading SD card is true random access, so no delays moving to another area of the “disk”.

Unfortunately as I said above, SD card interface bandwidth on 192 is significantly worse than 193, so not as big (if any) improvement in performance with SD maps.


----------



## TT'sRevenge (Feb 28, 2021)

Cool I have a 193 so maybe I _could_ make some use of the unused space  

Just out of curiosity, if you know, what would be the approx. read speed the 193 can do off an SD card? I'm actually quite suprised you were able to get larger cards working on the 192--that seems to be a good feat in itself!

On older Kenwood-Garmin units, the SD slot was basically all on the "Garmin side" and despite being able to read SDHC even on pretty old units, the SD slot speed was pretty slow--using faster SD cards made pretty much no difference. On newer Kenwood units the SD slot is more integrated and seems to be directly addressable to both the HU and the Garmin system. On later units like these they are able to read music off SD as well (older units the SD was solely for Garmin/nav functionality). However I have an inkling the SD reader performance in the 193 RNS-Es is still better than most of these mainstream car audio brands' SD readers--it actually seems quite good!


----------



## pcbbc (Sep 4, 2009)

Not sure about speeds, never had cause to measure them. But I can say a little about the architecture.

On the 192 there are 2 NEC UDP77016 DSP chips, one for each card. These have the majority of their software downloaded to them from the RNSE at boot, although some of the MP3 decode is burnt in ROM from the looks of things. Luckily their SD Card hardware was sufficiently generic to allow for a SDHC implementation, plus the SDHC spec seems to have been intelligently designed such that it might be possible to upgrade legacy SDSC hardware to support SDHC via software only. However the NEC DSP instruction set was NOT completely documented anywhere I could find, and you can read about all the help I got disassembling the code over on EEVBlog.

Anyway, the DSP are responsible for the MP3 decode and all SD card access. There is an API for reading/writing sectors from the SD for file system access at the RNSE end, and then presenting the DSP chip back with what sectors of the card should be read and presented to the DSP MP3 decode engine. This saves pointlessly sending all the MP3 data over to the RNSE, only to have to send it back for the DSP to do the decode. When the DSP is doing MP3 decode duties it can’t also be supplying the RNSE with data read from the SD card and vice versa. Hence the prohibition on simultaneous maps access and MP3 playback.

On the DSP chips the SD cards can be read via DMA into the onboard DSP RAM. Transfer of data between DSP RAM and RNSE is then via a 16 bit wide data port that must be serviced via IRQ at both ends. So with no DMA either side this looks to be a substantial performance bottleneck for both RNSE and DSP.

The 193 units are completely different. The RNSE has a much improved SOC with far more integration, although still using SH4 architecture as per 192. As a result the 193 has a built in SD Card interface right on the SOC silicon, complete with DMA access for card read/write operations. So no need for the separate DSP chip, or the overhead of transferring all card data over the 16 bit data port.

On the flip side 193 doesn’t have the DSP, or indeed any other dedicated hardware, to assist with MP3 decode. All MP3 decode is done on the SH4 in software, but the improved 193 SH4 CPU is clocked faster than on the 192, so that more than makes up for the additional overhead of having to do a software decode.

I would add that speed of SD cards is far less important for reading than writing. Quoted card performance is all about write performance, since that’s the main consideration for digital cameras. Read performance of all cards is almost certainly guaranteed to exceed their write performance. Therefore for these types of application (which only ever read data) any bottlenecks you see are almost certainly due to the hardware implementation, and not the card speed. That’s certainly the case with the RNSE.


----------



## SwissJetPilot (Apr 27, 2014)

This might be a really stupid question, but is it possible to "dumb down" a 4GB or 8GB SD card so the RNS-E reads it as a 2GB SD? These 2GB SD cards are getting a bit hard to find and the ones I've seen are a bit pricey compared to higher GB SD cards.


----------



## FNChaos (Nov 30, 2016)

I believe you can format a 4gb SD card to work as a 2gb card as long as the 4gb isn't a SDHC (HC interface isn't backward compatible). 

That said, you'd need access to an older version of Windows or DOS since commands like 'diskpart' & 'fdisk' are no longer available.


----------



## TT'sRevenge (Feb 28, 2021)

SwissJetPilot said:


> This might be a really stupid question, but is it possible to "dumb down" a 4GB or 8GB SD card so the RNS-E reads it as a 2GB SD? These 2GB SD cards are getting a bit hard to find and the ones I've seen are a bit pricey compared to higher GB SD cards.





FNChaos said:


> I believe you can format a 4gb SD card to work as a 2gb card as long as the 4gb isn't a SDHC (HC interface isn't backward compatible).
> 
> That said, you'd need access to an older version of Windows or DOS since commands like 'diskpart' & 'fdisk' are no longer available.


HC and XC are actually not "interfaces" but just partition formats and addressing.

Older devices which can't read higher than 1/2/4GB* "standard" (SDSC) SD cards just can't address the space higher than the 1/2/4GB limits. This can be a hardware limitation (the card reader hardware) or a software/firmware limit, depeding on the controller and the system. Many older devices that were not able to read HC cards have had firmware updates to read SDHC and beyond their initial limitations. Of course the majority of old SD devices didn't have such updates possible or available from manufacturers.

*There's actually capacity limits in original SD cards at different levels due to addressing limits of older controllers. Technically speaking original SD can go to 4GB but some devices were limited at 1GB or 2GB. See: https://en.wikipedia.org/wiki/SD_card#Storage_capacity_and_compatibilities



> SD version 1.00 assumed 512 bytes per block. This permitted SDSC cards up to 4,096 × 512 × 512 B = 1 GB...
> 
> Version 1.01 let an SDSC card use a 4-bit field to indicate 1,024 or 2,048 bytes per block instead.[87] Doing so enabled cards with 2 GB and 4 GB capacity...
> 
> Early SDSC host devices that assume 512-byte blocks therefore do not fully support the insertion of 2 GB or 4 GB cards. In some cases, the host device can read data that happens to reside in the first 1 GB of the card. If the assumption is made in the driver software, success may be version-dependent. In addition, any host device might not support a 4 GB SDSC card, since the specification lets it assume that 2 GB is the maximum for these cards.


Technically speaking 4GB SDSC is possible but all cards produced at 4GB are SDHC due to the SD "regulations". So 4GB can be "officially" formatted either way; and it's also possible to unofficially format cards in a variety of ways.

If you want to go the other way and partition/format _smaller_ it probably will work but depends on the device and since I don't have a 192 RNS, I couldn't say how it works on that. Def. worth a shot though! There are lots of 3rd party formatting utils out there that let you do stuff like this, even if you can find a way to do it with built-in Windows stuff.

*But, given the pcbbc firmware allows even 192 units to use larger cards**, isn't a better idea to just use that? *

More general SD info:

In terms of the formats:
SDSC = FAT file system
SDHC = FAT32 file system
SDXC = exFAT file system

The trick with SDXC is that exFAT is not free for anyone to use. It requires a licence from MS in order to use (at least legally/legitimately). So for that reason there are actually many devices on the market which were marketed with "SDHC up to 32GB" support which will actually work fine if you use the above trick, only going from XC-->HC. Going above the 2GB limit of original SD_ is_ often a hardware limitation; but going above the 32GB "limit" of HC is often simply a difference in format and nothing more. To do this, all you do is format an "XC" card with FAT32, essentially making it an HC card with greater than 32GB size. An awful lot of "HC limited" devices can actually then use 64, 128, etc. "XC" cards without any software or firmware update at all--they just see them as higher-space HC cards and use the space accordingly. Again it doesn't work on _every_ device but actually works on quite a lot of them. The RNS-E seems like it also _can't_ do this but the pcbbc fw makes it possible 

As for the "interfaces"... There _are_ several different protocols or interfaces for reading/writing cards, but these really aren't related to capacity limits and more importantly *are all backwards compatible*. So even a card that can work on say SDR104, can still work fine on a reader/writer that only supports old-skool original SD mode @ 12.5MB/s max (note: some controller and connection limits make it much slower than even that). *Of course the capacity limits of the controller/reader/firmware all still apply.*

Physical and electrical card differences start arising with UHS-II which can support 156MB/s modes and 312MB/s interface modes but these cards have a second set of pins to accomplish this. _However_ if these cards are put into a reader that does not have UHS-II support they still function fine, all the way down to original SD mode, using the still-existing original 9 pins (8 pins microSD). UHS-III additionally extends transfer rates even further, using the same "second set of pins", but again is backward compatible on the original pins with older SD devices.

There's also SD Express which uses a more direct type of connection to PCIe for very high speeds, but even then you could use those cards on an older device just the same. Apart from the capacity limits, SD is pretty darn good for backward compatibility.


----------



## pcbbc (Sep 4, 2009)

You can’t convert a SDHC card to SD(SC) just by reformatting.

The address to read/write data (in either standard) is a 32bit value. On SD(SC) cards that 32bit value is interpreted as a byte offset, which limits the addressing to 4GB maximum. The SDHC spec redefined that offset to be an LBA index (512 byte sector number) instead, so now the maximum addressable space is 4GB x 512 = 2TB for a SDXC card.

There’s also a special initialisation command required for SDHC/XC cards that a reader that is only SD(SC) capable won’t send. This ensures that a SDHC/XC card won’t start operating erroneously in a device only expecting SD(SD) cards.

Also there was a complete redesign of the CSD register structure, which gives many of the parameters of the card, including card size, for SDHC. The only change for the move to SDXC was that some spare bits in the SDHC CSD card size field were allocated to extend the size beyond the 32GB SDHC specification limit.

However, with my current beta firmware, there’s no need to be hunting around for 192 compatible cards. Support is added for SDHC cards up to 32GB with purchase of the feature pack.

DISKPART command line *still* available on Windows 11? although no idea why you’d want to dumb down a 4GB card to 2GB, as stock 192 RNSE is perfectly happy with 4GB cards as long as they are SD(SC) variety, and not SDHC.


----------



## TT'sRevenge (Feb 28, 2021)

Ah I stand corrected on the HC-->SC bit. I thought it was possible with a 4GB card at least, as from the information I'd read before it seems 4GB cards are sort of a "hybrid" but they are always officially produced as HC cards. I'm guessing in this case 4GB SC cards probably have some kind of premium on them and aren't worth buying since they probably cost too much. 

So just to clarify, on stock fw, a 192 RNS-E can only read up to 2GB cards normally and then can't use an HC 4GB card even if you try to format it otherwise? To get a [working] 4GB you'd have to buy a "special" 4GB SC card for it to work? Man I'm really glad I never had to deal with a 192 unit! 🤣 Must have been a nightmare trying to use those with music files. I mean I get SD cards were smaller at the time it was new but getting closer to 2010, it must have been a headache. I'd imagine most people were just using the iPod interface or AUX in those days...or using like 128kbps MP3s.


----------



## pcbbc (Sep 4, 2009)

Absolutely correct with your summary.

SDHC cards only came out in 2006, and RNSE first released in 2004. Theres also a 500 track limit, so anything over 4GB (even if it was possible at the time) wouldn‘t have been much use. And the bigger the card, the slower it loads.


----------

