Hello all. I am working on Sm1000 hardware circuit design. My first step is to design complete circuit of "SM1000 Version F" available on GitHub. I completed this part, I used almost same components that mention in the schematic but few of them are alternate. My second step is to test the power circuit of Sm1000, I completed this part too and verify+5V and +3.3V power circuit. My circuit takes three different veroboard to complete and I aslo connected VDD, AVdd and grounds of all veroboard together and verify (short circuit or not). I connect all the components exactly as on the schematic-F. In third step I am using STM32F407 discovery board and upload the"dfuse file" available on the github and follow the procedure same as mentioned on github. During upload I verify the product ID and vendor code exactly as mentioned on GitHub. In forth step, I start connecting SM1000-F with STM32F407 as per the schematic design F.
During these four steps I faced some problems and looking for a kind response from all experts. 1. When I upload dfuse file to stm32f407 discovery board, it shows upload successful "file size of 293KB but when I opened the properties of stm32 memory shows only 8KB or sometime 20 KB of data in it. 2. Stm32F407 have 100 pins on two sides, mentioned as P1 and P2, both P1 and P2 has 50, 50 pins... When I start connecting schematic F with discovery board of STM 32F407, I easily connect "PE1 with PE1" (nets connection) as mentioned.. but when I move towards power circuit of STM32F407 than I am confused, as on STM32F407 schematic F power circuit labeled as "U1B" grounds and VDD pins are not same as on the discovery board of STM32F407. Like Vref+,VBat, Bad, vdd2 etc. 3. When I turn on the circuit design on vero board, all the connections are okay, I measured and verify 5V in power circuit. But"pwr_led" available on schematic F (led-0) not ON and when i pressed PTT than"LED PTT" also not working but when i measured voltage with multimeter on these 2 LEDs than both LEDs have 3.3V available. I really appreciate your answers. Thanks in advance. Regards: Usman On Sat, Feb 6, 2021, 9:46 PM <e...@jacksch.com> wrote: > I realize that changing the CODEC would be a breaking change, and DMR > repeater/network operations wouldn't like it on their systems, but I would > like to demonstrate that there is an alternative to using patent-encumbered > CODECs. > > While I have been able to compile the OpenGD77 code, and I've located where > it calls the CODEC, I don't know enough about codec2 to do the integration > -- I'm really hoping that there are some gurus here that will help! > > -----Original Message----- > From: Greg Troxel <g...@lexort.com> > Sent: February 3, 2021 13:31 > To: e...@jacksch.com > Cc: freetel-codec2@lists.sourceforge.net > Subject: Re: [Freetel-codec2] Codec2 and OpenGD77 > > > I have long wondered about this sort of thing. A few thoughts: > > AIUI, DMR specifies lots of things and technically leaves hte codec > unspecified. So essentially all "DMR digital voice" is properly > called DMR/AMBE2, but because there isn't DMR/somethingelse, it's just > called DMR. > > Using one of the codec2 variants that has a similar bitrate, and > trying to leave everything in DMR that is specified the same seems > sensible. Ideally DMR, not having specified a codec, would have some > bits for a codec choice and some registry of bits but that would be > too much like IETF. > > One could perhaps play games with some kind of CRC, basically saying > that for codec2, one includes some specific bytes not in the frame > before the frame when calculating the CRC, so that DMR/AMBE2 nodes > would drop the bits, and DMR/codec2 nodes receive them. But I think > it needs to pass a regular DMR repeater, so it is fairly likely such > schemes will not work. > > Once you have two such radios, they should be able to talk simplex. > Probably, they can talk through a DMR repeater, because AIUI those > just retransmit the codec bits even though they demod the digital > channel. And you could probably even talk across a network but not > across familes that require transcoding (perhaps DMR/DSTAR currnetly > requires AMBE2/AMBE transcoding). > > This raises the issue that DMR repeater operators might not like this. > But of course with your own, or permission, it seems good. > > I've also wondered about DSTAR with codec2, but not gotten anywhere > near to really thinking about it. > > I don't think the M17 project is a good reason to refrain from doing > this if you feel like doing it. I am a fan of M17, but I don't think > it's good for the community to prune things off too aggressively. > > So far I have declined to get a DMR radio because I don't want to run > a proprietary protocol. If this works I might reconsider. > > 73 de n1dam > > > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
