Support for D-Star DV Fast Data #470
Comments
|
Hi Tim
Fast data on normal D-Star radios is a relatively new thing and certainly wasn’t around when my software was first written. The only data mode being used then was the relatively high speed DD mode on 23cms.
Although I own two radios that do this mode, an Icom ID-51 and a Kenwood TH-D74, I have not tried it out. So my comments are based on understanding the protocol and code rather than direct experience of the mode.
So to your questions:
- I don’t know. There is a bit in the header that is marked as being to indicate whether the payload is data or voice. This is not checked in my software currently. I hope that they use this bit for this mode also, although they’re not the same structure. The flags are the first three bytes of the D-Star header. I think any dump will need to be at a low level, i.e. the raw serial data from the modem so that any patterns in the data can be observed.
- I don’t know.
- The FEC is recalculated so that the bit errors don’t accumulate. This is something that Icom repeaters don’t do, and almost all repeaters for other modes do. I am certainly not willing to remove it as it can make a big difference to the received audio, and voice mode is the vast majority of the traffic. If we can find a way to reliably detect this data mode, then we can do something about the FEC regeneration.
To create the traces you need to go into the [Modem] section of MMDVM.ini and set either Debug=1 or Trace=1 (or both, I forget, and I’m at work currently) and logging to level 1 for debug messages. You shouldn’t need much data.
There must be a way to distinguish the voice and data modes, so I await your data logging with interest.
Jonathan G4KLX
Sent from Yahoo Mail for iPhone
On Wednesday, November 7, 2018, 02:39, Tim Stewart <notifications@github.com> wrote:
I've been testing D-Star DV "Fast Data" as implemented on the Kenwood TH-D74. I tried sending data via a ZUMspot only to find that it gets corrupted on its way through (juribeparada/MMDVM_HS#71 has an example of the corruption). MMDVMHost also reports a BER of ~12.6%.
I discovered that if I comment out all three calls to m_fec.regenerateDStar() in DStarControl.cpp, the data is able to pass through without corruption. It seems that all 72 bits of each voice frame are used for data and there is no FEC applied, which also probably explains the ~12.6% BER report.
Some things I don't know:
- Is there a way to tell when a voice frame contains "fast data" instead of voice+FEC?
- Do Icom and Kenwood implement the same fast data spec? (I hope so)
- Why is the FEC recalculated and reapplied in MMDVMHost? Is it so that the BER reports are effectively per-hop? Is there something important to the protocol going on?
To answer question 1, I'm planning to look for a difference in the packet that indicates whether voice or data is contained within the voice frames. I think there must be a way to tell the difference, because the demos I've seen of Icom radios doing fast data allow the user seamlessly transmit audio while a data transfer is ongoing and the radio degrades to slow data while sending voice frames. (The Kenwood does not seem to have this slow data capability)
I'm going to email Kenwood and Icom in an effort to answer question 2 (and maybe question 1?) and also ask if they have any specs to share.
I'm hoping that someone reading this can answer question 3 for me.
I'm interested in all this because I think that fast data + hotspots and the reflector system could be a powerful combination.
…-TimS, KG4BXH
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Jonathan, Now it totally makes sense why you would want to regenerate the FEC at each hop. Even though "error correction" is in the name, I was thinking of it as a mere checksum. I suppose it is lucky that the currently-installed Icom repeaters don't recalculate FEC, at least from the perspective of using fast data through them. I certainly don't have the experience to know how much it would improve repeater use if the repeaters also did the recalculation. I will grab some traces and post the results here. Thank you for the quick guide. If I can find the flag, I should be able to put together a patch that disables the recalc only in the case that fast data is in use. |
|
Yes, I know, I follow with attention |
|
Here are my findings so far. In fast data mode, I've found that the TH-D74 sends the following bytes in the first 21 voice frames before starting to send the actual data:
After the 21st frame, the contents of the voice frames begin to vary, presumably with the actual data I tried to send. Indeed, even when I send a single Here is a trace from the log that was generated by a D-RATS transmission as it started up and advertised that I was online: So, my theory is that there is something special about Anyway, if my theory is correct, we should be able to support fast data through hotspots (and repeaters?) by turning off FEC recalculation in the case that we see 21 of these in a row. I wonder if there's a "re-enable voice" sequence that indicates we should re-enable FEC, supporting Icom's apparent ability to move between the two modes in a single transmission. (I say "apparent" because I think this is possible based on the Icom video that demos text and image sending while also being able to send voice during the transfer). Maybe that's what |
|
I should note that this dump was created by MMDVMHost with the FEC recalculation disabled, which is why you see a 0% BER. Also, I said above that "I imagine that 9-byte sequence itself validates against FEC." If memory serves, these bytes contributed to the 12.6% BER in my original tests, so I think my statement is wrong. I'll double-check and confirm, though I don't think it affects my theory much overall. |
|
That is very very interesting. What you say makes sense. I think I can move forwards with what you have told me. If you could investigate the Icom mode switch, and also if Icom use the same system, I would appreciate it. I have some ideas and I'll try and implement them next week. Unfortunately the gateway will also need modifying which is not ideal, but necessary. |
|
Hi, I have done some tests with the same file (sent.log) and my ID51 with Fast DV data. Unfortunately it looks different from Kenwood format: |
|
I've realized that not always starts with the same data sequence, after repeating the same transmission with a ID51. For example, if I transmit a single "A" (I "cleaned" the log for better understanding): And if I repeat the same "A": |
|
I did more experiments, trying to decode the frames. Now I transmitted: "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789" I got: My guess: The data payload seems to be scrambled with: 70 4F 93 40 64 74 6D 30 2B E2 4F 93 (not sure about 64 and E2). If I de-scramble the payload: |
|
It looks like the Kenwood data is the easiest to support. I think the data marker is transmitted multiple times to make sure that you receive it. You'll find that 21 frames occurs a lot in D-Star and is the distance between sync frames, so it sort of makes sense to use that as the basic unit of data transmissions. Once I have reliably detected the data mode, I'd just switch off the FEC code and let it continue. I'd probably also regenerate the data marker also for good measure. I'm still looking at the Icom version. In theory switching off the FEC will be fine if the system switches back to voice, you just won't get the benefit of the FEC for the rest of that transmission. I do wish that Kenwood and Icom had used a bit in the header instead or as well as, to make my life easier. |
|
I am going to repeat the same tests with a ID-4100A and see if I get the same results. Something that I forget to mention: after all my tests with ID-51A, the first frame could be one of the following two possibilities:
Anyway, it seems to me that the large structure "C" is always in any Icom fast DV transmission. |
|
Unfortunately, I don't have any Icom hardware to test with :( I'm hoping to get an Icom ID-4100A by the end of the year, though. I have received an initial response from my email to Kenwood:
The last point could mean the D74A implements a simpler subset, I suppose, since it doesn't support switching back and forth between fast and slow. I haven't gotten a negative response from either Icom or Kenwood support about getting tech specs, so I'll update here when I have any answers there. Maybe there is some shared property of the bytes I saw ( Anyway, I plan to poke around a bit more with the TH-D7A this week and compare to the other posts here, in case I can discover anything. Thanks for looking at this! |
|
I've added some code to the D-Star support in the host. It should detect the use of fast data mode, and log it. It should work on RF and network although the ircDDB Gateway needs to be modified before we can send fast data over any network. For now, if you can test/modify the code that I've added for the fast data mode. |
|
I will test at night here |
|
I had little time for testing today, but I could check:
|
|
I've added data marker regeneration on RF and network traffic. I've checked the ircDDB Gateway and it does no AMBE FEC regeneration so fast data should pass through it without problems. The only potential issue is the DTMF decoder which could trigger and blank the data. This will need testing to make sure what goes in, comes out unchanged. I'm hoping that we can get this finished soon. |
|
BTW in your data, I wonder if element C is your RF header, scrambled. The only way to be sure would be for someone else to generate some Icom fast data with a dissimilar set of callsigns and do a comparison. |
|
I will test the changes tonight. |
|
It seems to me the block "C" doesn't change: I used different D-Star fields YOUR, RPT1, etc (except the callsign, I've used always the same), even I transmitted accidentally in simplex with the 4100, and I captured the same "C" structure, something curious. I will be out of the town for 10 days, then I will be not able to do more tests until come back. |
|
The changes look good to me so far. I was able to send and receive the same text using an echo test, and I get the Kenwood message in the logs. Now I'm hanging out on REF030D in D-RATS if either of you are around and want to test. |
|
I've shared a file via D-RATS in case one of you decide to test via REF030D while I am away. I realize this may not work yet, but I thought it might be fun to try. Goodnight! -TimS, KG4BXH |
|
That's very pleasing. I am still worried about the DTMF processing in the gateway which could potentially corrupt the data if triggered by random data. I will look to switch it off in data mode. I also need to think about the older D-Star Repeater software, whether to upgrade it or not. It will be interesting if there is a switch in the Icom data mode to go back to audio, as things stand it should work anyway, but any following audio won't have the extra processing that audio gets now. Sorry I wasn't on D-RATS but I live in the UK and the time difference killed that, as well as other things. |
|
I suspected you were in the UK and it was a long shot :) Also, my pi-star decided to restart all services at 3:30am EST anyway, so that killed the test after a while... need to turn that off. So, to be clear, my D-RATS test is now over, heh. Anyway, I'm still waiting on potential docs from Kenwood and Icom. That would be really nice if one of them could just tell us how it works. I'll see if I can find someone willing to test with me, given that I have only one radio. |
|
I think I could help out with testing. I have a ID51 at least but neeed
to figure out how fast data works.
|
|
I'm in the same boat Flo. I have a TH-D74 and an ID-51 and haven't used fast data on either of them. That's why it's never been added to my work before. I've updated the ircDDB Gateway to bypass all DTMF handling when fast data is detected, but it's on a branch because I can't build it currently. It'll be rolled into master when it's been compiled cleanly. |
|
Ok deal. I will try to set this up with the gateway from the branch and
test.
|
|
In my case, I enabled Fast DV data from ID-51 menu (DV Set->DV Fast Data->Fast Data->ON), and then simply I send the data using the serial port of the radio at 38400 bps:
If fast data is OFF, all data will be sent as slow data as usual. |
|
I finally have my fast data equipment up and running. Sorry for the delay. Anyone up for a test (across reflectors)? |
|
Hi, yes we can do the test just suggest which ref and time. |
|
@phl0 I hope you're asleep right now! If not, I hope to be on 30C in about 30 minutes. |
|
@timclassic Are you still on there? If so I am going to start my machines. |
|
@timclassic I am on REF030 D now. Seems like I am the only one :) U still there? |
|
Is this sufficient for a test result?
|
|
I've only tested so far with my TH-D74A. Here are my results with the latest code from master. I did an echo test. MMDVMHost logs: The logs show 21 voice frames corresponding with 10 blocks, which I believe is empty voice data combined with the slow data for the screen message. Then the data starts and you can see "switching to fast data mode." However, just before the switch to fast data, we receive a single voice frame with a BER of 14.6%, when the block sequence is starting again, and I believe this is voice frame 1 in block 1.
All looks well with this test except for the corruption at bytes 21-28. These bytes correspond exactly with "1st voice" in block 1 if you look at section 7.3 of the translated PDF. In #470 (comment) above, I worried:
I think this is what we are seeing here. I don't understand the overall control flow well, but from what I've read this particular requirement may not fit well with the current implementation. @g4klx, what do you think? Would it be straightforward to set aside voice frame 1 (always voice+sync) for one round and then handle it once the next voice+data frame is received and the mini header is available? Regarding @phl0's log, I don't know how to explain the three 14.46% BER voice frames (sequence numbers 0-2). @phl0, is it possible that your RX started late? What kind of radio was it? Also, I still plan to try with my ID-4100 but I expect I'll see the same issue there. For what it's worth, I think we're very close to the correct solution here. |
|
@timclassic Are you still online/on air? |
|
Guess it was a one time issue. Did some DStar Queries to " E". |
|
(@phl0 I'm sorry we didn't connect--I only saw your post right as I was shutting down for the night. I really hope you didn't trade any sleep to be ignored by me!) |
|
@timclassic Never mind. Sleep is overvalued :) Want to make a new sked? My equipment is still on the table :) |
|
I did test again with @timclassic
|
|
Mentioned this issue in an article I have written on D-Star Picture Mode, which will appear in the December 2020 issue of RSGB RadCom Magazine. The article talks about transfer of images using DV Fast Data mode, and unfortunately this issue prevents users of low-cost MMDVM hotspots (Pi-Star & others) from transmitting images in Fast Data mode. Would be nice to see D-Star DV Fast Data mode fully implemented and supported in MMDVMHost; anything I/we (@timclassic @phl0) can do to help progress of this issue towards a fix? Thanks, |
|
@hipmark, I'm planning to revisit this issue over the next week or two. It has come up again in my own projects since I'm trying to build a digital radio using a Kenwood TM-V7 and the MMDVM_PCM code + MMDVMHost modifications[1] described at the DUDE-Star Radio Project. As a part of this I would love to get DV Fast Data working. Conceptually I think I know what needs to be done--I still believe that #470 (comment) captures the final piece of the puzzle (famous last words). I hope to send @g4klx a PR with a solution in the next week or two. Maybe @phl0 will be up for another test? [1] I think the MMDVMHost modifications are represented by #647. Maybe there are additional changes? I haven't diffed the two repos to check. |
|
Hi Mark
I originally implemented fast data mode about two years ago based on data dumps from an ID-51 and a TH-D74 and the somewhat obscure description in the D-Star specification. Within the MMDVM and I think ircDDB Gateway was to disable the FEC regeneration and DTMF processing for the duration of the transmission. If fast data is detected then it puts an entry into the log to say so.
It should pass through them without difficulty, but I may have missed something. If you do find a bug then I would be most interested.
I got my RadCom today so I held off before replying. I think it’s the first time that the MMDVM has been mentioned in the magazine. I keep meaning to do a write up of the project, but never get around to it.
Jonathan G4KLX
Sent from Yahoo Mail for iPhone
On Friday, November 13, 2020, 22:32, hipmark <notifications@github.com> wrote:
Mentioned this issue in an article I have written on D-Star Picture Mode, which will appear in the December 2020 issue of RSGB RadCom Magazine. The article talks about transfer of images using DV Fast Data mode, and unfortunately this issue prevents users of low-cost MMDVM hotspots (Pi-Star & others) from transmitting images in Fast Data mode.
Would be nice to see D-Star DV Fast Data mode fully implemented and supported in MMDVMHost; anything I/we can do to help progress of this issue towards a fix?
Thanks,
Mark, M5BOP
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi Jonathan, thanks for your rapid reply. Please see comments from @timclassic above - he believes that #470 (comment) captures the final piece of the puzzle needed to fully implement DV Fast Data mode (famous last words). Tim is going to take another look at the code based on his findings and send you a PR if he can get to the bottom of this.
I believe MMDVM is a fantastic piece of work that has really been under-sung - many people know about Pi-Star, but really don't understand the excellent engineering under the covers that has made low-cost multimode digital hotspots possible. From comments I've read, I'm sure the creators of Pi-Star agree entirely - and for this reason I think you really should write an article about your journey in developing MMDVM. I'd never written for a radio mag before, but with the excellent editing skills of Giles G1MFG at RSGB, I'm really pleased with how my humble efforts turned out! 73 & stay safe! |
|
Tnx @timclassic. I'll get my equipment ready. Need to set D-Rats up on my new computer. Which reflector are you on usually? |
|
Hey Tim @timclassic,
Thanks for all your hard work on Fast Data patches for MMDVM-Host under #667 - sorry for delay in reply until now; have been busy as was our baby’s first Christmas and so wanted to have some focussed family time, but now free to do some testing if that is still helpful / get an update on any testing you’ve done with @phl0
Do I need a special build on my Pi-Star MMDVM hotspot to test; or have Pi-Star now taken the required MMDVM-Host build? I’m currently running Pi-Star 4.1.3 with Linux
Kernel 4.19.97+
Thanks @g4klx for another year of sterling support on MMDVM!
Best regards,
Mark, M5BOP
On 15 Dec 2020, at 01:44, Tim Stewart <notifications@github.com> wrote:
@phl0 and @hipmark, let me know if either of you would like to do some fast data testing now that #667 has been merged. I'm happy to make a sked, and weekends are generally good for me.
@g4klx, thanks in general for all the work on MMDVM!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
D-Star Picture Net is held weekly on REF072D, so that is where I usually hang out for picture TX/RX. Mark, M5BOP |
|
"Conclusion The ID-51 E3 release somehow switches to Fast Data Mode as soon as it transmits GPS Data. Once it does this it does not send the End of Transmission frame. This behavior confuses both MMDVM gear and Icom gear. Both will then wait for a timeout and then decide the transmission is gone. Hence the 3s delay on the IC-E92D before end of transmission beep and the garbled R2D2 tail signal on the MMDVM. The workaround is to switch GPS data off. Downgrading the ID-51E Anniversary Edition to firmware release pre-November 5th solved the issue." https://www.f4fxl.org/buggy-icom-id-51-and-id-5100-firmware/ |
|
@hipmark I'll be on the D-Star Picture Net tonight as well. I plan to send images from both my IC-9700 and my TH-D74 (by way of RS-MS1A). @hipmark and @phl0, I'll look up your contact info on QRZ and we can work out further testing that way, so we don't have to pollute this Issue with scheduling details. I suspect we can close this issue once we do some a bit more testing with images and D-RATS. |
|
I would like it confirmed that these changes don't affect normal D-Star voice operation. I'm not concerned about the modem/hotspot changes so much, more the changes within the host.
On Thursday, 31 December 2020, 01:41:52 GMT, Tim Stewart <notifications@github.com> wrote:
@hipmark I'll be on the D-Star Picture Net tonight as well. I plan to send images from both my IC-9700 and my TH-D74 (by way of RS-MS1A).
@hipmark and @phl0, I'll look up your contact info on QRZ and we can work out further testing that way, so we don't have to pollute this Issue with scheduling details. I suspect we can close this issue once we do some a bit more testing with images and D-RATS.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@g4klx I've been using the Fast Data changes on both of my hotspots since submitting #667 and voice traffic has been working well. I also created #675 today so I could watch logs in a more useful way while listening to REF030C for a few hours. All looks well. Maybe some others (@hipmark and/or @phl0, perhaps?) would be willing to run the latest MMDVMHost for a while and report back with their results, so we could become more confident in the changes? (Oh, and I did attend the D-Star Picture Net and it went well! The image I sent had good reports from others and the images I received were as good as or better than the quality reported by others on the net. @hipmark sent a nice picture of the moon.) |
|
Hi Jonathan @g4klx & Tim - is it possible to build a version of MMDVMHost for ARM with Tim’s fixes and inject that into my Pi-Star hotspot - if so I can then use that as my primary hotspot to help validate that changes have no negative impact on D-Star voice. If so, can anyone advise how to do this/provide suitably built components - not familiar with MMDVMHost build process!
@timclassic - what is your callsign? Can then use QRZ to find e-Mail & set up a test sked with you for this weekend.
Cheers Mark @hipmark
(glad you liked the Moon pic Tim!)
… On 2 Jan 2021, at 00:20, Tim Stewart ***@***.***> wrote:
***@***.*** I've been using the Fast Data changes on both of my hotspots since submitting #667 and voice traffic has been working well.
I also created #675 today so I could watch logs in a more useful way while listening to REF030C for a few hours. All looks well.
Maybe some others ***@***.*** and/or @phl0, perhaps?) would be willing to run the latest MMDVMHost for a while and report back with their results, so we could become more confident in the changes?
(Oh, and I did attend the D-Star Picture Net and it went well! The image I sent had good reports from others and the images I received were as good as or better than the quality reported by others on the net. @hipmark sent a nice picture of the moon.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@hipmark, I have tested this on a ZUMspot by building both MMDVM firmware + MMDVMHost on the Pi itself. I've gone through my notes and stepped through the build process again, writing down everything I did. These instructions were validated using a ZUMspot RPi running Pi-Star v4.1.2. Build and Flash MMDVM_HS FirmwareFirst, I recommend building a new MMDVM_HS firmware and flashing it to the ZUMspot board so you can take advantage of the fix in juribeparada/MMDVM_HS#135. Without this change, there are some data patterns that the MMDVM firware will interpret as an End Of Transmission sequence. Here are the steps I followed on my ZUMspot, adapted from the instructions at https://www.hamradio.com/images_managed/misc/H0-017019_ZUMspot_Duplex_Quick_Start_Guide_1_2020.pdf in the section called "Building firmware on Pi-Star." Hopefully your hotspot also uses the MMDVM_HS firmware. If so, do the following, replacing # Log in to your pi-star as the pi-star user, then make the disk writable
rpi-rw
# Stop services that would interfere with installation
sudo systemctl stop pistar-watchdog.timer
sudo systemctl stop pistar-watchdog.service
sudo systemctl stop mmdvmhost.timer
sudo systemctl stop mmdvmhost.service
# Install required packages
sudo apt-get install gcc-arm-none-eabi gdb-arm-none-eabi libstdc++-arm-none-eabi-newlib libnewlib-arm-none-eabi
# Build and install the latest stm32flash utility (not sure if this is required, but I did it)
cd ~
git clone https://git.code.sf.net/p/stm32flash/code stm32flash
cd stm32flash
make
sudo make install
# Build the MMDVM_HS firmware
cd ~
git clone https://github.com/juribeparada/MMDVM_HS.git
cd MMDVM_HS
git submodule init
git submodule update
cp configs/ZUMspot_RPi.h Config.h # replace with appropriate config
make
# Flash the ZUMspot with new firmware
sudo /usr/local/bin/stm32flash -v -w bin/mmdvm_f1.bin -g 0x0 -R -i 20,-21,21:-20,21 /dev/ttyAMA0Build and Install MMDVMHostThe following steps assume the disk is writable and services are still stopped after following the MMDVM_HS instructions above. Now, build and install MMDVMHost: cd ~
git clone https://github.com/g4klx/MMDVMHost.git
cd MMDVMHost
make
sudo make install
# This build of MMDVMHost can't open the modem when started via systemd for some reason. I haven't
# figured out the root cause yet, but forcing "dialout" into the service's supplementary groups resolves
# the problem for me:
sudo mkdir /etc/systemd/system/mmdvmhost.service.d
echo "[Service]" | sudo tee /etc/systemd/system/mmdvmhost.service.d/modem-access.conf >/dev/null
echo "SupplementaryGroups=dialout" | sudo tee -a /etc/systemd/system/mmdvmhost.service.d/modem-access.conf >/dev/null
sudo systemctl daemon-reload
# Reboot as an easy way to bring everything back online
sudo shutdown -r nowTestingAt this point I think you can use the hotspot as you normally would. Be careful running an update, however--it may overwrite the updated version of MMDVMHost you've just installed. The debug logging for D-Star frames has also been enhanced as of #675, so you can see more details in |
|
Hi @timclassic
Thanks so much for your detailed notes, much appreciated! I have used them to upgrade my Pi-Star hotspot (constructed from a Pi-Zero with an AliBaba-sourced MMDVM_HS radio hat) and can report that I have a working upgraded hotspot and both audio and picture transfer works well under the new build. The only problem I have had is that the OLED display on my hotspot is no longer operational/updating, but I’m pretty sure that will be something to do with configuration parameters in the STM32 flash build - any tips on how to resolve much appreciated, but even without the display the modem side of things works a treat and is much improved for picture transmission in Fast Data mode, as well as retaining full functionality for audio RX and TX. As a test, I used the upgraded hotspot to take part in the busy D-Star Picture Net this week (as well as my day-to-day REF001C operating) with my Icom-9700 as the client. I recorded all incoming audio from the net onto the 9700’s SD card, as well as listening and had clean audio - no unexpected issues. Also had positive reports re. my transmitted audio! Best of all, I had very good reports for my Pictures, sent in Fast Data mode - not something I have achieved before using this low-cost hotspot - in fact Jef ON8NT sent me via e-mail a perfect copy of the picture that I had transmitted! So a clean bill-of-health as far as I am concerned @g4klx and a gold star to @timclassic for his contributions - thanks Tim. Will, of course, keep on testing! What is your callsign Tim? Thanks, Mark M5BOP |
|
Here’s a copy of my Fast Data transmitted picture from this week’s Picture Net, as received and sent to me via e-mail by Jef ON8NT. In case you’re wondering, it’s a picture of our church video streaming set-up!
Cheers, Mark M5BOP |
|
Hi @timclassic, @g4klx
Managed to solve the OLED problem by doing that old important thing when you have such a problem - reading the manual! or in this case OLED.md on Jonathan's Github! Re-ran the MMDVMHost make using: make -f Makefile.Pi.OLED Now have a much-improved MMDVM hotspot with a working OLED status display - I am a very happy man! Thanks! |
|
@hipmark Sorry for missing your questions earlier--my callsign is KG4BXH. Also, I'm glad you figured out the OLED configuration. I don't have an OLED screen on my ZUMspot so I didn't have any slam-dunk solutions for you. I wasn't on the picture net last Wednesday, but I'm pleased that it went well! I plan to attend the next one, and hopefully we'll run into each other. I've been doing a lot of listening and some talking using my patched hotspot, and I still haven't run into any problems with D-Star voice. |
I've been testing D-Star DV "Fast Data" as implemented on the Kenwood TH-D74. I tried sending data via a ZUMspot only to find that it gets corrupted on its way through (juribeparada/MMDVM_HS#71 has an example of the corruption). MMDVMHost also reports a BER of ~12.6%.
I discovered that if I comment out all three calls to
m_fec.regenerateDStar()in DStarControl.cpp, the data is able to pass through without corruption. It seems that all 72 bits of each voice frame are used for data and there is no FEC applied, which also probably explains the ~12.6% BER report.Some things I don't know:
To answer question 1, I'm planning to look for a difference in the packet that indicates whether voice or data is contained within the voice frames. I think there must be a way to tell the difference, because the demos I've seen of Icom radios doing fast data allow the user seamlessly transmit audio while a data transfer is ongoing and the radio degrades to slow data while sending voice frames. (The Kenwood does not seem to have this slow data capability)
I'm going to email Kenwood and Icom in an effort to answer question 2 (and maybe question 1?) and also ask if they have any specs to share.
I'm hoping that someone reading this can answer question 3 for me.
I'm interested in all this because I think that fast data + hotspots and the reflector system could be a powerful combination.
-TimS, KG4BXH
The text was updated successfully, but these errors were encountered: