travisgoodspeed / md380tools Goto Github PK

Feel free to try fC instead of CC when using @radare : https://github.com/travisgoodspeed/md380tools/blob/master/annotations/2.032/reg.r

maybe useful for you
MCU.pdf

In the stock firmware, the beep tones emitted by the radio are at a fixed volume that ignores the setting of the volume knob. Some users are using a hardware mod as a work around.

Close this issue when it is possible to mitigate the beep tone volume in some manner.

(This is a top usability complaint for this radio/stock firmware. Should also be on the feature list for any possible replacement firmware.)

Note: It looks like @aeickho has made progress on this in commit 5a9f350 Currently README.me does not list the features available in the experimental firmware.

regarding also #66

The problem is also relevant for spi_flash_addl_config.

Chirp data sources for DMR-MARC's data dump would allow repeaters to be automatically loaded.
http://www.dmr-marc.net/cgi-bin/trbo-database/datadump.cgi

Do you need/want a virgin codeplug image for an MD380? There's one on a mail truck with my name on it due to arrive tomorrow. If so, let me know what command I need to run and I'll post it.

The Chirp driver needs to support Banks, or Zones as the official software calls it, in order to be self-sufficient for analog repeaters.

to new menu items for {en,dis}able

• talk groups
• private calls

When a user finds a frequency with DMR activity, a standalone radio should be capable of identifying the color code, time slots and talk groups in use that would allow the user to monitor and capture the necessary information.

Close this when a standalone radio is capable of being tuned to a specific frequency to identify the color code(s) and some number of talk group/time slot pairs that have been recently used on that frequency.

(This is an attempt to define some basic sniffing functionality that would be helpful to a user in the field. Note: using the term "sniffing" for identifying the DMR parameters on a single frequency, as opposed to "scanning" which generally is associated with automatically checking multiple frequencies for activity.)

Some UI/UX ideas:

• When decoding audio the radio shows CC/TS/TG.
• A menu entry shows the last N CC/TS/TG used on the current frequency.

See #58 for some progress on this issue.

Chirp is presently ignoring the timeslot. Close this issue when it can be configured.

To round out the scanning/promiscuous listening capabilities, a patch to enable monitoring all color codes would be useful.

Does it work with internal bootloader of stm32, so boot pin needs to be connected?

Firmware updates come in an encrypted form, but they are decrypted by the radio during the loading process. md380-dfu should be able to send the encrypted update, letting the radio take care of the decryption.

Close this issue when the md380dfu can flash firmware

Interesting find that I just saw reported on the MD_380 Yahoo group. The MD_380 windows application has the ability to read and write the radio's calibration data, The software will save the settings in an 8 KB binary blob with a .test extension.

To access this, you need to change the line testmode=0 to 1 in setting.ini.

The path on a default Windows 7 install is C:\Program Files (x86)\MD_380\MD_380\SoftWare_EN\setting.ini

The testmode=1 line is in the [setup] group of the .ini file.

The process is:

1. Change the settings.ini file as described above.
2. connect the radio
3. Start MD-380.exe
4. Hit Control-T which will read the data off the radio.
5. Click "Save Test Data" which will save a .test file with an 8 KB binary of the calibration data.

It might be worth adding a note to the README to backup the radio's calibration data before doing too much experimentation.

I can post a screenshot if anyone can't run the Windows software.

Version: ce47c27

export and reimport from an more color image, the image is broken

md380-fw --unwrap ../firmware/D002.032.bin flash.img
md380-gfx --dir=imgout --firmware=flash.img extract
md380-gfx --firmware=patched.img --gfx=0x80f9ce4.ppm write
md380-fw --wrap patched.img experiment.bin
md380-dfu upgrade experiment.bin

diff files from the to different bin files:
https://gist.github.com/aeickho/d87b4a2da69a9af9e194

The official MD380 software ends the channel list at the first empty channel. For compatibility, the Chirp driver should either enable the empty channel for appearance' sake or instruct Chirp not to allow empty channels.

See the screenshots in #55 for both fonts

Letters g, j, p, q & J are all chopped off at the bottom. the J is especially problematic as it's in call signs & people's names (Jim, Jerry)

MotoTRBO RAS (Restricted Access System) avoids out current sniffing. It would be nice to understand the system and to sniff its audio.

Forked from a request by @BabaYog in Issue #19.

see #82..

@ladyada reported the md5sum checksum compare from @dl8bb don't work on cygwin

6945c79

Currently, only a split offset is supported in Chirp, as that's the way offsets are implemented natively.

Close this issue when + and - offsets are supported, to make the list look all nice and spiffy.

If one changes the DMR-ID via utilities - addl. funct. the DMR-ID only stays until power-cycle. Then the original DMR-ID from the codeplug is in use again.

Is this a bug or a feature? Could be both, hi.

when trying to write users.csv to a MD380 UHF I get

SPI Flash ID: 10 dc 1
local variable 'size' referenced before assignment

I think this part is responsiible

def flashgetid(dfu):
buf=dfu.spiflashgetid();
print "SPI Flash ID: %x %x %x"%(buf[0],buf[1],buf[2])
if (buf[0] == 0xef and buf[1] == 0x40):
if (buf[2] == 0x18):
sys.stdout.write("W25Q128FV 16MByte\n");
size=16_1024_1024;
elif (buf[2] == 0x14):
sys.stdout.write("W25Q80BL 1MByte\n");
size=1_1024_1024;
else:
sys.stdout.write("Unkown SPI Flash - please report\n");
size=0;
return size;

The procedure runs direct to "return size" without setting "size" to a value

Any suggestions?
tnx kind regards
Alex

what is the usb backend that you use for pyUSB that can handle larger usb transfer size than 4096 bytes?

Using the stock firmware, the menu functions aren't accessible while the radio is receiving. Menu operations will be aborted if the radio starts to receive while in the menus. It should be possible to enter the menus and change settings while on a busy channel.

Close this when it is possible to change zones while receiving.

Ideally menu operations should possible while receiving a signal and decoding audio. However, it would be preferable if it was possible to activate the menus and abort the receive operation allowing the user to regain control over the radio.

(No idea if this is remotely feasible to fix via patching, but felt it would be helpful to have this on the list of issues for replacement firmware and or patching if possible.)

M0IVQ has been kind enough to send us the remaining bitfields for the codeplug memories. Close this issue when they have been imported into our CHIRP driver, and perhaps also into the patched firmware headers.

MD-380%20Memory%20Map.xlsx

I've read today at Yahoo MD-380 statementL

The hardware of the MD380 will not support anything other than DMR and Analog. You cannot write > firmware to do the other formats due to the limitation of the existing hardware.

Could someone comment this? Is it true? I would be a very sad message.

On fe04162 I added function to use the Firmware µCOS semaphore functions.

The usage on DebugLine is only an example...

I's for the: "Radio VFO-Mode"

I've fresh installed a Debian Jessie,
during Make I have this error:

../../md380-fw --unwrap ../../firmware/D002.032.bin unwrapped.img
DEBUG: reading "../../firmware/D002.032.bin"
Traceback (most recent call last):
File "../../md380-fw", line 203, in
main()
File "../../md380-fw", line 185, in main
md.unwrap(input)
File "../../md380-fw", line 114, in unwrap
header = header.unpack(img[:256])
struct.error: unpack requires a string argument of length 256

No problem on Ubuntu, all library and requirement satisfied.

At the moment, this texts are included:
static wchar_t wt_addl_func[] = L"Addl. Funct";
static wchar_t wt_datef[] = L"Date format";
static wchar_t wt_debug[] = L"Debug";
static wchar_t wt_disable[] = L"Disable";
static wchar_t wt_enable[] = L"Enable";
static wchar_t wt_rbeep[] = L"M. RogerBeep";
static wchar_t wt_userscsv[] = L"UsersCSV";
static wchar_t wt_datef_original[] = L"Original";
static wchar_t wt_datef_germany[] = L"German";
static wchar_t wt_promtg[] = L"Promiscuous";
static wchar_t wt_edit[] = L"Edit";
static wchar_t wt_edit_dmr_id[] = L"Edit DMR-ID";
static wchar_t wt_no_w25q128[] = L"No W25Q128";

Please support me to find the correct words.

next week, i'll look on the calling functions .. to see with task is involved
and i'll look to find the I2C address

on #40
-->
Software Control Watch Dog Serial Clock
Software Control Watch Dog Serial Data

Patch the firmware version string (bytes?) that gets display from the Radio Info menu to differentiate from stock unmodified firmware. A one byte difference might help avoid some confusion.

Note Radios that are configured to display text lines on start up from the codeplug won't show the PoC || GTFO logo from the patched firmware.

I filled out some of the Chirp driver to import md380-dfu and run upload_codeplug and download_codeplug. I had to patch Chirp to ignore some serial port stuff, and added a NO_SERIAL "flag" to the Radio driver. I don't know if it's the cleanest or sanest way to make Chirp understand, but it'll do for testing for now at least.

Patch for Chirp (hg diff output, anyway):
https://github.com/mach327/md380tools/blob/master/chirp_md380_NO_SERIAL.patch

Current md380 driver for Chirp:
https://github.com/mach327/md380tools/blob/master/chirp/md380.py

None of this is ready to be merged or used for anything but development - but it does successfully upload and download codeplugs to/from the radio. Someone will have to decide how Chirp will include the MD380 stuff eventually, if the driver will be distributed with Chirp.

In the meantime, this can be tested and worked on by symlinking the chirp driver chirp/md380.py into Chirps drivers/ directory, and symlinking the md380tools repository into {whichever python you're using}'s site-packages directory (or wherever else you like in your python path).
For future hg noobs like me, looks like you can apply the chirp patch on your cloned Chirp repo to play with asking like so:
hg patch ../path/to/chirp_md380_NO_SERIAL.patch --no-commit.

We need a flashy demo intro, or maybe a few.

Does anyone know is it possible to reprogram band in radio? Is it firmware or hardware issue?

Chirp can now read and write the DMR ID number. Close this issue when the other settings are also editable.

Take a look at https://wiki.dg9vh.de/dmr:tytera_tyt_md-380:experimentelle_firmware_von_travis_goodspeed_-_kk4vcz

Maybe you'll refer at it in README.md for german-speaking-users.

I would take this page actual with development as it is possible for me...

Hi,

if you were running the make flashdb in top-directory /md380tools on a Debian-System it could not find the md380tool. Modifying the call to ./md380tool makes it running.

We need the ability to show additional icons, indicating features such as promiscuous mode and a custom scanner. These could go in the original row, or they might be shown along the right-hand side of the display.

Limor Fried, recently licensed as AC2SN, has an intro video on the MD-380 and installing the experimental firmware on Windows with Cygwin. Unfortunately, it's really basic as she/(they) are filming and discovering at the same time, but it might be useful to some. Close this issue when it is determined if it worth linking to this in the README.md or not.

https://www.youtube.com/watch?v=mAS3nH6wuNk

No bug, just a link to a description by DF2ET:
http://ham-dmr.nl/?p=5592

Hi, would it be possible to replace the accents in user.csv, for example by re-encoding it in utf-8, I did it like that with a standalone python script but I'm just beginning with python so there must be a better way :
import unicodedata
f = open('users.csv', 'r')
w = open('users_utf8.csv', 'w')
s = f.read()
s1 = unicode(s, 'utf-8', errors='ignore')
s2 = unicodedata.normalize('NFD', s1).encode('ascii', 'ignore')
w.write(s2)
w.close()

73 de Tom, F8COD

Patches should be written as Radare2 scripts. It'll be a bit tricky building against the dev version, but worth it for long term portability between firmware releases.

Forward port the "scanning" patches, listen to all talkgroups and all private calls, to the current firmware version D2.034.

The current patches are against firmware version 2.032.

Issue dded for tracking/documentation purposes.

The MD-380 CPS software shows a Unique Device ID and/or serial number that is stored in the code plug (.rdt) header but doesn't seem to be in the code plug image contents AFAICT. Might be read from the radio as part of a different transaction?

Notes:

• serial number for my radio is blank, but unique device ID is filled out.
• some code plugs (.rdt) that I've seen have serial numbers, but may be from (older?) radios?
• The unique device ID is at bytes 0x16D - 0x178 of the .rdt file in two parts
  • The part that is displayed first as '257505Q' is stored at 0x172-0x178, as bytes in reverse order (Q505752).
  • The part after the letter seems to be stored as a 40 bit (!?) integer at 0x16D - 0x171.

md380-dfu might be speaking to (1) an unpatched Application, (2) a patched Application, or (3) the Recovery image. It should have functions to detect which of these it is communicating with, so that an error can be printed when new users forget to hold PTT and the button above it when reflashing their radios.

The vendor software, MD_380, has operations to read or write the radio's date and time setting.

md380tools should have an option to set the radio's time and date using the host's current time.

I'm putting this in as a place holder for now. Currently, I don't have a windows VM built yet that would let me trace the USB operations with VMware. (Need to find out if USB tracing is also available from VirtualBox.)

Notes:

• Using MD_380 window software, connect the radio, select Edit -> Time Setting. This brings up a dialog box with buttons to read or write the radio's time and date.
• The radio briefly goes into "PC Progam USB mode", and then returns to normal operation.

Giorgio reports that the VHF model of the MD380 doesn't like the addition of the CSV to the SPI Flash. Somehow, it is damaging the codeplug.

Assigning to @aeickho, as the CSV database is his contribution. I'll try reproducing this on my VHF MD380 tonight.

Motorola's Basic Privacy can be made compatible with the MD380 by hooking aes_cipher() to return a motorola keystream. Close this issue when we can make (poorly) encrypted calls between Motorola and Tytera radios.

TYT's official editor for the MD380 issues its codeplugs as .RDT files, which are just a thin DFU header applied to the binary codeplug.

Close this issue when md380-dfu properly creates and reads the headers when the extension is .rdt.

After the libusb error radio reboots. Firmware runs without issues

2302 2301 33f400 1024
1024
1033
(OK, 0, dfuDNLOAD_IDLE, 0)
2302 33f800 672
672
681
(OK, 0, dfuDNLOAD_IDLE, 0)
Exception usb.core.USBError: USBError(19, u'No such device (it may have been disconnected)') in <bound method Device.del of <DEVICE ID 0483:df11 on Bus 002 Address 006>> ignored