Oh yes and picture can be added as attachments, just keep them to a few 100k. Or link to a URL. I'm happy to write a blog post on yr project if you like, might get others interested.
Can think of other applications for yr module too - like in radio modems/FSK work. Cheers, David On 31/08/16 09:47, e...@vk5kbb.com wrote: > I do have some pictures, > > I wasn't sure if they could be added as attachments. > > On this design to aid in layout simplicity and speed up the design (only > spent 2 or 3 hours on it on a lazy Sunday arvo) I had swapped ADC and > DAC pins. > I foolishly thought it would be a matter of changing a few defines in > the code to accommodate this (but was wrong). > > As it turned out even after recording all the ADC1/2 and DAC1/2 in the > source I am not 100% convinced it worked as when I am feeding audio from > the PC the error LED cycles in and out when there is no modulation. As > soon as there is modulation on the audio to the PC the error light stays > off. > > RT light stays on fine. > > I thought initially that there may have been a porting issue with the > tuning and hence the slow cycling but since then I have modified the PCB > so that the inputs are reversed and can use the original firmware with > only changes of the GPIO's for the switches and LED's. > > Acts the same way so I have to ask if this is normal when there is no > modulation on the data stream? > > As for circuits I am now re-hashing the board layout to remove the > speaker amp, 5volt regulator and EEPROM to save space as none of these > are needed when installed into a radio. > > I am also returning the ADC and DAC pins to original so that the only > code that needs changing is that for the switches and LED's > > That will make the hardware generic and then I will get a quote for > having it made cheaply in China if people are interested. > > > > Cheers > > Eric. > > > > On 2016-08-31 00:24, David Rowe wrote: > >> Nice work Eric. Do you have any photos? >> >> Good to see this sort of innovation happening with codec 2 and the open >> hardware SM1000 platform. >> >> Also it would be great if you can publish your hardware/software work >> under the GPL/TAPR open hardware licenses for others to build upon. >> >> Cheers, >> >> David >> >> On 28/08/16 09:37, e...@vk5kbb.com <mailto:e...@vk5kbb.com>wrote: >>> No confusion and thanks for the input. In the end looks like my >>> windows DFuSe was not working correctly and I found that DFU-UTILS >>> could be installed with a simple apt-get function and I didnt need to >>> build it. From there DFU-UTILS happily installed the 210,080 byte >>> .BIN (didnt need to be converted) and I could immediately tell it >>> worked because it took roughly 30 seconds to down load to the >>> hardware. So the modified code for the new hardware works (although >>> as the new hardware uses different ADC pins the changes are not >>> trivial). Now I will go back to evaluating various IDE's because this >>> is not an environment that makes code development very easy or >>> efficient. Basically right now I am editing in an IDE on a windows >>> machine via a network drive and then making on the Ubuntu machine. >>> The hardware tested ok and I now have an SM1000 that fits into a >>> match box so I can put it inside a speaker microphone. I am however >>> now redesigning the PCB to reduce it a further 20% in size (mainly >>> removal of more un-needed parts, 5V reg, EEPROM, and speaker >>> amplifier) with the plan to graft it into my FT817 so that it is >>> activated when the digital mode is selected. I am also putting the >>> ADC pins back where they were so that people need only change the >>> sm1000_leds_switches.c code to reflect the pin changes. I will >>> eventually rewrite the code so that the ADC's and GPIO's are defined >>> in a single .h hardware definition to make the code hardware >>> portable. I do this as a general rule of thumb so that for example in >>> this case every time the hardware changes the 56 (or more) instances >>> of ADC1/2 all dont need to be edited. Cheers Eric On 2016-08-24 >>> 15:04, Walter Holmes wrote: >>>> Steve, I hope this doesn't just add more to the confusion, but the >>>> .bin file for the SM1000 is about 227k that is flashed from Linux, >>>> but if I extract that same code down to my Windows machine using the >>>> DFU program it's 1025k. I am not part of the code team, so I have no >>>> idea why there is such a difference, but that's just an observation >>>> I have witnessed. I say this only so that you don't let the code >>>> size between environments make you think it's not still correct. Try >>>> it out to see what happens. I suspect the Windows side probably has >>>> a lot of extra overhead as do most Windows apps, and clearly the >>>> Linux side is a great deal more efficient. All the best, Walter/K5WH >>>> -----Original Message----- From: Steve >>>> [mailto:coupaydevi...@gmail.com <mailto:coupaydevi...@gmail.com> >>>> <mailto:coupaydevi...@gmail.com <mailto:coupaydevi...@gmail.com>>] >>>> Sent: Wednesday, August 24, 2016 3:33 AM To: >>>> freetel-codec2@lists.sourceforge.net >>>> <mailto:freetel-codec2@lists.sourceforge.net> >>>> <mailto:freetel-codec2@lists.sourceforge.net >>>> <mailto:freetel-codec2@lists.sourceforge.net>> Subject: Re: >>>> [Freetel-codec2] Fresh build of SM1000 firmware on a windows >>>> machine. Just a note, but on my Ubuntu 16 32-bit Virtual Box, it >>>> resulted in 1305108 for the sm1000.elf, and after the 'objcopy' >>>> conversion, the .bin result was 305884. I had to download the V >>>> 1.7.1 ZIP file manually, as the web site gave me a short version >>>> that was gimped and wouldn't unzip. I just downloaded it manually >>>> after registering and put it in the 'dl' directory. Also the name >>>> changed to en.stm32f4_dsp_stdperiph_lib.zip so I dropped the 'en.' >>>> before putting it in 'dl'. I hope all that makes sense. >>>> ---------------------------------------------------------------------------- >>>> -- _______________________________________________ Freetel-codec2 >>>> mailing list Freetel-codec2@lists.sourceforge.net >>>> <mailto:Freetel-codec2@lists.sourceforge.net> >>>> <mailto:Freetel-codec2@lists.sourceforge.net >>>> <mailto:Freetel-codec2@lists.sourceforge.net>> >>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ Freetel-codec2 >>>> mailing list Freetel-codec2@lists.sourceforge.net >>>> <mailto:Freetel-codec2@lists.sourceforge.net> >>>> <mailto:Freetel-codec2@lists.sourceforge.net >>>> <mailto:Freetel-codec2@lists.sourceforge.net>> >>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> ------------------------------------------------------------------------------ >>> _______________________________________________ Freetel-codec2 >>> mailing list Freetel-codec2@lists.sourceforge.net >>> <mailto:Freetel-codec2@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freetel-codec2 mailing list >> Freetel-codec2@lists.sourceforge.net >> <mailto: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 > ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
