https://github.com/noeltimothy/sqleye ]]>

;;; Problem 9 – Pack consecutive duplicates of list elements into sublists.

(defun my-pack (elements)

(when elements

(if (listp (car elements))

(if (equal (caar elements) (cadr elements))

(my-pack

(cons (append (car elements) (list (cadr elements))) (cddr elements)))

(cons (car elements) (my-pack (cdr elements))))

(my-pack (cons (cons (car elements) nil) (cdr elements))))))

It’s picturesque, at least

]]>1. Yes, you are correct. I will fix this in the article. It looks like I had multiple versions of the code and forgot to change a variable name.

2. If you only use a value for freq between 0.0 and 1.0 then it will not overflow, but otherwise yes it could. You are correct that it represents the normalized frequency (actual/sample_freq). For digital systems like this it is common to work with normalized frequencies only. You could add checks to enforce this here if you like. 0 to .49999… is valid for only positive frequency, but if you produce both sine and cosine output–as if you were generating a complex valued signal exp(-2*pi*i*f/fs)–then you can have 0-1.0 frequency. However, the NCO must be modified to produce a cosine output simultaneously. The best way to do this in my experience is to precompute a 90 degree phase offset and add it to the accumulator, then in nco_step32() you would save a sine value and a cosine value based on the accumulator + phase offset. For a costas loop you will want to have the NCO produce both sine and cosine value simultaneously to ensure that the two are synchronized.

As for the use of 256, rather than 255, this is due to the number of entries and the scaling for fixed point. On line 23, when we initialize the table, we divide by 256 because there are 256 entries (0 through 255). Then to scale the frequency correctly we must multiply by 256 as well so that the two cancel out (line 47). You could choose any value here, but it would affect your fixed point representation and complicate the index decoding. We use 256 because it is a power of 2, and as a result the calculation of the index for the sine table is straightforward, a right shift. If a different number were used, then it would be more complex to convert to an integer offset for use with the table.

3. Using a higher resolution table will improve performance, but you also must consider the effects of precision of the sine table. Here we use uint8_t which is 8 bits. Traditionally this provides at most 48 dB of SNR regardless of how many entries you have in your table. If your application requires a lower noise floor then you must increase the precision for the sine table as well. You have two limits on accuracy: one is the number of table entries and one is the precision of those entries. If you have an infinitely large table but each entry is only 8 bits, you will still be limited to 8 bits of accuracy on the output.

There are other ways to increase the performance if you do not have enough memory for a larger table: linear interpolation is simple and computationally efficient. For instance, let us assume that the index value is 12.3456. In this current implementation, we would discard the fractional part (>> 24 on line 60) and use only the value at sintable32[12]. If you do linear interpolation, you could instead compute (1-0.3456)*sintable32[12] + 0.3456*sintable32[13], which would be much more accurate. Of course, this linear interpolation operation must be translated into fixed point in order to implement it.

My advice would be to prototype this in MATLAB (or GNU Octave, the open source version) in order to determine what your accuracy requirements are and then match the final implementation in C to these requirements. You can also experiment with table size vs. table precision tradeoffs more easily in MATLAB than in C.

Good luck with your work!

]]>I cannot edit my previous queries, hence posting multiple queries. Apologize for the same.

]]>All the time I am assuming that uint32_t is 32-bit. ]]>

I ran your code and came upon few queries. These are not meant to criticize your work, but to clarify my doubts.

1. Line-33 uses “sintable”, which should be “sintable32″.

2. Line-47, the value of “n->phase” will overflow, since the output of calculation exceeds 32-bit. Is it fine?

3. Will using a very high resolution sine table (4096 point) gives better stability to my demodulation (BPSK using costas loop)?

Best regards.

]]>You can also restrict vote submissions by IP address – Meaning you can configure your server to accept votes from the web application, if web application is different then you can just configure server to accept requests from the web url()

I think it is better to use combinations of steps rather than just rate limiting by ip.

]]>