travisgoodspeed / md380tools Goto Github PK
View Code? Open in Web Editor NEWPython tools and patched firmware for the TYT-MD380
Python tools and patched firmware for the TYT-MD380
Feel free to try fC
instead of CC
when using @radare : https://github.com/travisgoodspeed/md380tools/blob/master/annotations/2.032/reg.r
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.
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.
to new menu items for {en,dis}able
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...
The Chirp driver needs to support Banks, or Zones as the official software calls it, in order to be self-sufficient for analog repeaters.
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.
what is the usb backend that you use for pyUSB that can handle larger usb transfer size than 4096 bytes?
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.
Chirp can now read and write the DMR ID number. Close this issue when the other settings are also editable.
regarding also #66
The problem is also relevant for spi_flash_addl_config.
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
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.
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"
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
Chirp is presently ignoring the timeslot. Close this issue when it can be configured.
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:
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.
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:
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.
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
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.
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.
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.
No bug, just a link to a description by DF2ET:
http://ham-dmr.nl/?p=5592
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:
See #58 for some progress on this issue.
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.
maybe useful for you
MCU.pdf
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.
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.
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.
Does it work with internal bootloader of stm32, so boot pin needs to be connected?
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.
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.
Does anyone know is it possible to reprogram band in radio? Is it firmware or hardware issue?
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.
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
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:
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.
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)
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.
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
.
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
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
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.)
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
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.
To round out the scanning/promiscuous listening capabilities, a patch to enable monitoring all color codes would be useful.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.