Hmm.
The difference of “Cell ID” between the two radios was surprising to me because I had assumed it was some kind of tower ID thing. Tim_S’s answer seems to match with my assumption. The part of my assumption that appears to be wrong is that they’d both have the same number at the same time.
Perhaps after a few days of data gathering I’ll be able to crunch the data and find out if they ever do have the same number.
I’m working on a project to log cellular signal information tied to GPS coordinates. Right now, I’m testing everything locally, and once the vehicle goes in the field, the BR1 will have an AT&T sim card to test how AT&T compares to Verizon in the ares of interest. But for now, the BR1 has a Verizon sim, so I can at least get some readings for my testing.
The max transit is broadcasting GPS in NMEA format on the local network segment to a raspberry pi, which turns that into latitude, longitude, and altitude, as well as grabbing the date and time from the GPS to form a timestamp for the record. Once that GPS packet is received and processed, the script then queries the max transit and max br1 for the cellid and strength individually, then fetches the undocumented items with a walk of .1.3.6.1.4.1.27662.200.1.12.1.1.1. It then stuffs everything into a complex data structure that is frankly ugly, then spits that record to a log file in json format. Originally I was using CSV for compactness, but after changing the fields and field orders too many times, I switched to json since the data format is self documenting. Every hour, that data is backed up to an on-board nas device, then nightly uploaded to a vps.
I’ve got the following data record saved from a max transit and a max br1. The record is stored in json format, and the entire record is retrieved from the two devices with back to back snmp queries within the code. The two devices have about 2 meters horizontal separation between each antenna, same model antenna, on the roof of a chevrolet suburban. Both devices are on Verizon Wireless. Both have the same plan, the alleged “unlimited” plan. This record was output using the pprint() function in python to make it easier to read. I left out the timestamp, latitude, longitude, and altitude readings as they aren’t relevant and I’m not keen on putting my GPS location in a forum. 
Transit:
{‘cellid’: ‘49667’,
‘signal’: {‘band’: ‘LTE Band 13 (700 MHz)’,
‘id’: ‘28933’,
‘mode’: ‘LTE’,
‘mystery’: ‘-1’,
‘rsrp’: ‘-86’,
‘rsrq’: ‘-9’,
‘rssi’: ‘-63’,
‘sinr’: ‘10’},
‘strength’: ‘-63’}
BR1:
{‘cellid’: ‘49696’,
‘signal’: {‘band’: ‘LTE Band 13 (700 MHz)’,
‘id’: ‘28933’,
‘mode’: ‘LTE’,
‘mystery’: ‘-1’,
‘rsrp’: ‘-85’,
‘rsrq’: ‘-10’,
‘rssi’: ‘-58’,
‘sinr’: ‘19’},
‘strength’: ‘-58’}
‘cellid’ is from .1.3.6.1.4.1.27662.2.1.2.1.6.1
‘strength’ is from .1.3.6.1.4.1.27662.2.1.2.1.5.1
everything in the ‘signal’ set is taken from readings within .1.3.6.1.4.1.27662.200.1.12.1.1.1, which is totally undocumented, and lacking a MIB hint hint. Through comparison with readings via the web interface and incontrol, I’ve mapped most of them. But the “id” and “mystery” ones I don’t have any way to identify properly.
‘rssi’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.3
‘sinr’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.5
‘rsrp’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.7
‘rsrq’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.8
‘mode’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.9
‘band’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.10
‘mystery’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.11 (and seems to always be ‘-1’)
‘id’ is from .1.3.6.1.4.1.27662.200.1.12.1.1.1.12
In the above record, the “Cell ID” aka ‘cellid’ is different for the two devices. But the ‘id’ from the undocumented items is the same.
