Nice work Jeroen, great to see you experimenting with a new voice mode! The LPCNet README:
https://github.com/drowe67/LPCNet has some examples of using command line options to configure different bit rates in the "Fully quantised encoder/decoder programs" section. -/- I am also WFH and have a few projects running. Mark, Bill and I are working on a new low MDS telemetry system for High Altitude Balloons (HAB) and other applications: https://github.com/drowe67/codec2/pull/101 and I'm also playing around with some Neural Net projects, including a LPCnet decoder for FreeDV 700C. Plus I've been on the air with VK3RV and Jose LU5DKI using KiwiSDR-assisted HF communications between Australia and Argentina (7.177MHz +/- QRM 1030 UTC each evening). With bad things happening in the world it's a good time to stay home and work on Ham Radio projects. Cheers, David On 1/4/20 7:08 am, Jeroen Vreeken wrote: > Hi all, > > During the last few weeks I had some more time available than expected > (working from home for obvious reasons) and finally got around to do an > experiment I wanted to do for a while now: implement and test a new mode > for use on VHF/UHF. > I really liked the idea of mode 2400B, but it is relativly wastfull with > bandwidth, and I also wanted to have a bit higher quality codec2 mode so > it can actually compete with analog FM. > So I tried something different: a 6000baud mode with raised cosine symbols. > A zero is encoded as an inversion, ones as a continuous level. > To prevent to much DC in the signal after each 9 bits a zero is inserted. > > Originally I wanted to use a higher bitrate LPCNet mode, but couldn't > figure out how to set it to anything other than 1733bps yet. So for the > time being I am using mode 3200, but can still swap it out later as > there is 4666bps available. > I used a frame length of 120ms, partially to reduce overhead, but also > to make it easier to switch to another codec later, 120ms can handle all > the current codec sizes: 20ms, 30ms, 40ms etc... > > In order to make each identification more standardised and to always > have a data channel available each frame has data. > Either 64bits in case of a voice frame, or 608 in case of a full data frame. > > Yesterday I did some on-air tests between my home and our local 70cm > repeater (the discriminator output is connected to the controller and > can be sampled directly). At home I used the packet input of my ft-817. > Using 5W this resulted in a near perfect (might need some finetuning) > signal over a distance of 11km. > > My current status can be found at > https://github.com/JeroenVreeken/codec2 in the m6000 branch. Be aware > that I have not extensively tested with real audio data yet, my tests > were with artificial voice data to be able to test easily. > Next step is to use the new lib for the actual repeater. It is currently > configured to receive both analog FM and mode 2400B, but it should not > be hard to switch 2400B out for 6000. Just need to check that the > correct amount of samples is used everywhere. That should enable some > real world tests. > > 73s, > Jeroen > > > p.s. some values from the README: > | second | frame > ----------------|---------|------ > baud | 6000 | 720 > inserted 0s | 600 | 72 > sync bits | 133.33 | 16 > --------------------------------- > voice bits | 4666.67 | 560 > used voice bits | 3200 | 384 > codec2 frames | 50 | 6 > extra data bits | 533.33 | 64 > control bits | 50 | 6 > reserved bits | 16.67 | 2 > --------------------------------- > data frame bits | 5066.67 | 608 > control bits | 83.33 | 10 > reserved bits | | 14 > > > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
