Jay, Indeed, the disadvantage of typing is that the simulator becomes somewhat inflexible, in a sense. I'm still not sure my typing scheme is good, but the only way to know is to try it. Just as an example, I initially thought every waveform should have a "starting time" field. Now I'm not so sure.
I will open source my package when it's more functional and when the typing system is better ironed out. I really don't know, at this time, whether different people writing their own digital comm packages is inefficient or not. There are many ways to implement such a package, and it may be that between several people we can explore the alternatives quicker, and then let people choose a "winner". Having said that, I do envision eventually to make my package capable of multiprocessing. Behind my vision of having "blocks" that take input and produce output, independently of other blocks, is to be able to assign each block to different processors. I have a separate package that explores these ideas (https://bitbucket.org/mbaz/chango). In digital comm, simulations can take so long that, even at Julia's speed, I see parallelism as necessary. I also expect to be able to interface to external sources and sinks -- chango.jl already can interface with a sound card in Linux. -- mb On Tue, Apr 8, 2014 at 11:18 AM, Jay Kickliter <[email protected]>wrote: > Thanks for the info. I've trying to come up with a type scheme. Say I > create some modulated symbols, then interpolate them with a nyquist filter, > then upsample and shift the signal with a mixer. It would be nice to know > the relative sample rate and center frequency of the signal, plus mod type. > But I can't quite see what makes sense until I actually start using the > code, which is why I haven't been typing everything yet. It sound like > you've given it a lot of thought. > > Are you planning on open sourcing your code, or is it too specific to what > you're doing? If you are going to open source it I'd hate be writing > duplicate code, especially if you have better ideas. I just want a decent > comms framework so I can pitch Julia to my company as an alternative to > Matlab. > > > On Tuesday, April 8, 2014 7:32:29 AM UTC-6, Miguel Bazdresch wrote: > >> Jay, >> >> I'm also writing a package to do digital communications simulation, to >> support my work both in research and in teaching. There's too little >> functionality at this point to make it worth sharing, but I thought I'd >> share a couple of ideas. >> >> I'm using julia's type system to define bits, symbols, and waveform >> types. They're all vectors of numbers, but the type works as a label or >> identifier. I think this makes it easier for students to build their >> simulations: they don't have to mentally keep track of the meaning of each >> vector. Also, it makes it easy to detect errors such as adding a bit vector >> to a signal vector. >> >> Using types like this makes it easy to carry simulation information >> around. For example, the waveform type has a field for the sampling >> interval, and my spectrum plotting function gets that information from the >> waveform itself. >> >> This also allows me to define blocks that take vectors of one type and >> output a different type. For example, a matched filter takes a waveform and >> outputs a symbol vector. With a large enough library of blocks, you can >> draw a diagram of your system and translate that into a simulation very >> easily. Any inconsistencies are detected by the type system itself. >> >> -- mb >> >> >> On Sun, Apr 6, 2014 at 4:02 PM, Jay Kickliter <[email protected]>wrote: >> >>> I didn't tag the subject with [ANN] since *Radio.jl >>> <https://github.com/JayKickliter/Radio.jl>* is barely a package yet. >>> But I am looking for feedback, feature requests, and hopefully some help. >>> >>> I'm mainly writing the package to support my work with space >>> communications, so I will be focusing on Phase Shift Keying and rectangular >>> Quadrature Amplitude Modulation. But Julia needs a general comms package. >>> If you have any needs/suggestions please let me know. >>> >>> I mistakenly re-implemeted some of *DSP.jl*'s functionality, and some >>> of what I've written is missing from it. Maybe Radio's filtering functions >>> should be moved to DSP? >>> >> >>
