[JohnS4]

The 4GLTE MIB also has a modular modem. I wonder what is inside that casing.

Audi's MMI Goes Modular: Swappable Chips Will Help Cars Keep Pace With Processing Advancements

Swappable chipsets will help cars keep pace with processing advancements.

www.popularmechanics.com

 

[JohnS4]

This is an interesting find

Home - Motion for Audi Connect

Disclaimers Motion for Audi connect services should be used only when it is safe and appropriate. Always pay careful attention to the road, and do not drive while distracted. Available on select models. Motion for Audi connect services are provided with the support of authorized affiliated and...

motionforaudiconnect.com

 

[DrGER]

This is an interesting find

Home - Motion for Audi Connect

Disclaimers Motion for Audi connect services should be used only when it is safe and appropriate. Always pay careful attention to the road, and do not drive while distracted. Available on select models. Motion for Audi connect services are provided with the support of authorized affiliated and...

motionforaudiconnect.com

Alas, not a replacement for the data connectivity found in the MMI 3G+ system. And it ties up the OBDII port. Looks to be a replacement for 3G emergency telematics in earlier MIB systems. Reports from some owners re this LTE "solution" have not been kind, e.g.: 3G Retrofit Recall BEWARE!!

 

[Augsie]

I did some digging on FCC.gov. Apparently the AH6A-US is actually an AH3A-US renamed simply for marketing purposes (I found an FCC "change in identification" application stating precisely this). An FCC query using the original FCC id of QIPAH3-US yields much more interesting results, such as a hardware interface overview manual and some internal photos of the module: OET List Exhibits Report

 

[DrGER]

@Augsie : It's too bad that Cinterion/Gemalto wasn't using the mini PCI form-factor in this generation of data modem cards (like their current generation of LTE modems: https://www.thalesgroup.com/sites/default/files/gemalto/iot-lte-cinterion-4G-modem-cards.pdf). I think we would have had a better chance at updating the internal data module from 3G to LTE. As it is, I can't find any reference to LTE modems that look anything like the AH3/6 modem card from (roughly) 10 years ago... --g

 

[Augsie]

The AH3/6 has the following signals on the 88-pin board-to-board connector:

• USB 2.0
• 8-wire asynchronous modem interface
• SIM interface
• analog audio
• PCM audio
• 10-pin GPIO
• ADC (used for antenna diagnosis only)

All of these are standard electrical interfaces. Furthermore, from what I can find (and the available data is scant), the more modern Cinterion modules are using a similar signal set. It doesn't look to me like it would be technically very difficult to adapt a modern 4G/5G module to interface with the MMI hardware-wise. IOW, if we knew the pinouts and electrical specifications then designing an interface board should be relatively straightforward. A primary hurdle to this is the limited technical information available--I haven't been able to even find pinouts on the Cinterion modules (although I haven't looked really hard).

Another approach, or perhaps a complementary one, would be to look at the Telit modules used in the European-market cars. Telit may be more open with their technical data.

As far as a replacement module, we needn't necessarily be confined to a Cinterion or Telit module. There are many factors to consider in choosing a module, a big one being ease of development which includes access to technical resources, tool costs, etc.

Before going too far, it would be appropriate to look at things from an MMI firmware angle as this is likely to be the most difficult part. We need to know how the software architecture pertaining to the embedded phone module is layered, which components will need to be reverse engineered and rewritten, etc.

 

[DrGER]

...
Before going too far, it would be appropriate to look at things from an MMI firmware angle as this is likely to be the most difficult part. We need to know how the software architecture pertaining to the embedded phone module is layered, which components will need to be reverse engineered and rewritten, etc.

My initial observations from poking around the QNX system (by way of SD card scripting) is that the US-market Cinterion modem is a USB device: Vendor 0x1e2d (Cinterion) Device 0x0055 (AHx) via /dev/serusb4:

/usr/bin/PSSBSSProcess -f /usr/data/pss.cfg -s pss_config -c HostAgent MonitorService IntegrityService AliveService AudioMatrixService PhoneService BSSService NetAccessService SIMService DataService DmlService MediaService MediaRMService SAIPService SAOPService RmssService RemoteCtrlService TTYdevService ModemService DSIService -k VerboseLevel=2 MonitorService.Port=2021 NetAccess.NADName=AH6 Phone2.DriverVendor=PHONE_VENDOR_CINTERION Phone2.DriverModel=PHONE_MODEL_CINTERION_AH6 Phone2.ATChannels=1 DialUp.NADModem1=serusb4

Given the age of these systems and the access to proper QNX development tools, I was thinking a direct LTE replacement for the AH6A-US modem card would have been worth experimenting with, but these don't seem to exist anywhere (that I've found). --g

 

[Augsie]

My initial observations from poking around the QNX system (by way of SD card scripting) is that the US-market Cinertion modem is a USB device: Vendor 0x1e2d (Cinterion) Device 0x0055 (AHx) via /dev/serusb4:

This makes sense.

Given the age of these systems and the access to proper QNX development tools, I was thinking a direct LTE replacement for the AH6A-US modem card would have been worth experimenting with, but these don't seem to exist anywhere (that I've found). --g

It seems that there is a small but non-zero chance that a more modern Cinterion chip/module could be sufficiently backwards compatible to the AH6A such that it offers some/most/all needed functionality without firmware changes other than some config settings, provided that the hardware can be interfaced to. I still don't think the hardware interface would be a big deal if we had the requisite technical information (e.g. pinouts). Even if we had to use the chip/module in BGA form that is quite workable for prototyping--the pitch / pin count isn't that bad and a solder template could be made to apply the paste. I'm more intimidating by the firmware. It would be interesting to see the software component that "Phone2.DriverModel=PHONE_MODEL_CINTERION_AH6" points to.

 

[Augsie]

Another thought I just had was to emulate the AH6A with a man-in-the-middle approach. Basically, the MMI could interface via USB directly to an ARM/PIC32-core uC which emulates the AH6A and relays data to/from the 4G/5G LTE module. The idea is that as far as the MMI is concerned, it's interfaced to an AH6A. The advantage of this approach is that there would be no need for custom firmware on the MMI side of things--so no need for QNX dev tools, etc. I suspect that the MMI/AH6A USB-comms could be sniffed and used to reverse engineer the command and data formats between the MMI and AH6A. The more I think about it, I think this might be the best approach. Of course, there might also be some discretes that would need addressing.

 

[JohnS4]

As it’s a modem it should use standard hayes AT commands.

 

[JohnS4]

I found this thread which discusses exchanging the mini pci-e modem board, (2g to 3g) sadly not in detail.

MMI 3GP + SIM US>EU stuck on 2G [Архив] - Turbo Quattro

Hello, I have done a conversion for a MMI 3GP with sim from US to EU. Only two thing still do not work, the tmc does not operate (using an existing EU radio unit). And the other one is the internat dataconnection is 2G. The unit is capable of UMTS 3G so it should connect in 3G. The simcard...

turbo-quattro.com

 

[DrGER]

@JohnS4 : Post #39 of the thread you referenced is interesting: looks like someone managed to rework an MIB2 system to use a Cinterion ALS6A-E LTE modem (and some familiar user-names in the thread, too). --g

 

[Augsie]

Does anyone know what class of USB device the Cinterion module enumerates as?

 

[Augsie]

So I discovered that the AH6 phone module is based on the Cinterion PH8 platform. The PH8-P AT command set can be found here:

https://www.gs-m2m.de/fileadmin/Bilder/GSM_Module/Module/PH8/PH8-P_AT_Command_Set_V03.320c.pdf

These docs may also be useful:

https://media.digikey.com/pdf/Data ...ets/Gemalto PDFs/Differences_Between_Selected_Cinterion_Modules_V11_8-21-19.pdf

https://ptelectronics.ru/wp-content/uploads/cinterion_bgs2-ehs5-migration.pdf

And as a guess answer to my own previous question, I suspect the AH6 is a CDC ACM class device.

 

[DrGER]

...
It would be interesting to see the software component that "Phone2.DriverModel=PHONE_MODEL_CINTERION_AH6" points to.

The QNX process I noted above is launched by shell script PSSBSSProcess.sh, which is called by process /ifs-root/usr/bin/srv-starter-QNX at system startup. That script tries to identify the installed module by looking at the USB serial devices:

   if test -a /dev/serusb4 ; then
  
      echo "====================="
      echo "= DETECTED NAD: AH6 ="
      echo "====================="     
      touch /HBpersistence/PhoneModule_AH6
     
      # Just duplicate this information in /tmp
      touch /tmp/PhoneModule_AH6
  
   elif test -a /dev/serusb1 ; then

      echo "======================="
      echo "= DETECTED NAD: TELIT ="
      echo "======================="
      touch /HBpersistence/PhoneModule_Telit
     
      # Just duplicate this information in /tmp
      touch /tmp/PhoneModule_Telit
     
   else
      echo "======================"
      echo "= DETECTED NAD: AC75 ="
      echo "======================"
      touch /HBpersistence/PhoneModule_AC75
            # No duplicate of this information
   fi

The HBpersistence file is used subsequently to launch the correct version of the PSSBSSProcess, noted above.

Poking at shared library /efs-system/pss/pssbss/usr/lib/libphoneservice.so with strings(1), I find references to:

PHONE_VENDOR_CINTERION
PHONE_MODEL_CINTERION_AH6
PHONE_VENDOR_CINTERION

and a large set of "AT" command strings (way too many to post here).

And these related USB device definitions in /ifs-root/etc/umass-enum_def.cfg:

##########     USB SERIAL converters

#Prolifics USB Serial converter
vendor=0x067b,device=0x2303,type=SER,driver=devc-serusb_prolific,args=-b 57600 -F -S -v

#MULF cmd line below
#vendor=0x067b,device=0x2303,type=SER,driver=devc-serusb_prolific,args=-b 57600 -F -S -v -o disable=rx

# Telit UC864
vendor=0x1bc7,device=0x1003,type=SER,driver=devc-serusb,args=-vv,interface=1,ipbuff=8192,opbuff=12288

# Cinterion AH6A
vendor=0x1e2d,device=0x0055,type=SER,driver=devc-serusb,args=-vv,interface=1,ipbuff=8192,opbuff=12288

 

[Augsie]

Cool. So I'm guessing the "Prolifics USB Serial converter" is connected to the serial interface on the AH6A. The AH6A's USB appears to use the CDC class. That makes things really straightforward. I'm beginning to feel more comfortable with the prospects of this from a software standpoint.

A good next step may be to figure out the following:

• pinout of the MMI main board <-> phone module connector
• pinout of the AH6A module 80-pin connector

I think I may have just found the second item. Look at pages 18-20 in this doc: https://www.e-kom.com/Datasheet/Gemalto/Starter-Kit-B80_Datasheet.pdf . They're also given here: https://www.e-kom.com/Datasheet/Gemalto/Starter-Kit-B80_Datasheet.pdf

Technically, with the 80-pin connector pinout and the phone module itself we should be able to reverse engineer the main board connector.

An interesting (and available) option for the module itself could be the Cinterion PLAS9-X (PLAS9-X Rel.1 Thales DIS (formerly Gemalto) | RF/IF and RFID | DigiKey and https://www.thalesgroup.com/en/mark...tity-and-security/iot/iot-connectivity/products/iot-products/plas9-x-high-speed).

 

[DrGER]

Not quite that: the umass-enum_def.cfg references some QNX user-space device drivers that we don't get in production systems; devc-serusb_prolific is one of them. We only get /ifs-root/sbin/devc-serusb, which is responsible for the /dev/serusbN interfaces:

crw-rw-rw-  1 root        15,   1 Jan 01 00:19 serusb1
crw-rw-rw-  1 root        15,   2 Jan 01 00:17 serusb2  
crw-rw-rw-  1 root        15,   3 Jan 01 00:17 serusb3 
crw-r--r--  1 root        15,   4 Jan 01 00:19 serusb4

And used to communicate with the modem during an active 3G session through pppd:

pppd /dev/serusb4 logstatus debug novj defaultroute confstr noresconf nodetach noipdefault receive-all usepeerdns require-ns nocrtscts ipcp-max-failure 100 ipcp-max-configure 100 allow-null-authuser  password  logfd 3 idle 300

BTW, launched by the PSSBSSProcess when an internet function (e.g., Audi connect, on-line destinations, Google Earth) is started.

It seems to me an LTE modem that behaves sufficiently like the AH6A could be defined in umass-enum_def.cfg to use the standard QNX serial USB device driver with the proper VENDOR and DEVICE values. --g

 

[Augsie]

I know next to nothing about QNX and only a bit of Linux, so bare with me.

Does it appear to you then that they aren't using the serial interface but only USB to communicate with the AH6A? From the PH8-P AT command set document, page 17, it states that the modem interface can be either on the asynchronous serial interface, a logical channel of the USB composite device, or the first multiplex channel if the multiplex mode is activated. The application interface can be assigned to a logical channel of the USB composite device or the second multiplex channel if multiplex is activated. I suppose if we knew what AT commands were sent on startup/launch we would know for sure how they are doing these assignments.

 

[DrGER]

I think it really is as simple as it's supposed to be. In general, the first argument to pppd is a tty (i.e., character serial) device name. Thus, /dev/serusb4 is the character serial interface to the associated USB device (here, the AH6A-US modem). More info on QNX pppd here: pppd

More clues about how H-B's implementation uses the data modems, this from the PSSBSSProcess config file /efs-system/pss/pssbss/usr/data/pss.cfg:

# ====================================================================
# [NetAccessService / NAD AH6]
# ====================================================================

#**********QNX USB CONFIG**********************

# NAD Cinterion AH6 (USB)
# -------------------------------------------------------------------
NetAccess_AH6.PortType            = Serial
NetAccess_AH6.PortNumber          = serusb4
NetAccess_AH6.Bitrate             = 115200
NetAccess_AH6.UpdatePort          = serusb1
# --- Serial configuration ------------------------------------------
NetAccess_AH6.SerialChannels      = 3
NetAccess_AH6.SerialPortNames     = MODEM_PORT, SIMAP_DATA, PHONE_ATC
NetAccess_AH6.SerialPortNumbers   = serusb4, serusb2, serusb1
NetAccess_AH6.ShareDataPort       = TRUE

 

[Augsie]

The configuration looks straightforward but I'm still trying to work out how it aligns with the interface configuration options outlined in the command set datasheet that purportedly is applicable to the AH6A (PH8-P AT Command Set, link in earlier post). Cinterion recommends a modem interface and application interface (but it looks like the application interface may be optional?). Here we have MODEM_PORT, SIMAP_DATA, and PHONE_ATC. It seems like a safe assumption to assume that MODEM_PORT is the modem interface. Maybe PHONE_ATC is the application interface (although the naming really wouldn't make sense at all)? Since it doesn't appear that this is a USB composite device, they may be using "multiplex mode". The referenced document describing the multiplexer protocol is 3G TS 27.010 V2.0.0 -> http://www.3gpp.org/ftp/tsg_t/tsg_t/tsgt_04/docs/pdfs/TP-99119.pdf . Additionally, if MODEM_PORT is indeed the modem interface, then it is likely that they are not using the asynchronous serial interface of the AH6A at all.

I can't find anything to explain the SIMAP_DATA channel. Perhaps they are running custom firmware on the AH6A?

Another possibility is that they are using a single interface to the AH6A but are using their own schema to logically partition the comm's into the different channels (MODEM_PORT, SIMAP_DATA, PHONE_ATC) internally. Or they could be doing the same but using multiple interfaces (via multiplexing) on the AH6A. One of these options could make sense as it would be prudent to design the software architecture to make the MMI's modem interface agnostic to the greatest possible degree to the modem hardware (so different modems can be readily adapted).

I'll keep digging into the datasheets.