Re: [casper] Compiling design

[Mugundhan vijayaraghavan]

Hi Heystek,

This is (probably) because the yellow blocks, when you look under the mask,
already have gateway ins and outs. In conventional system generator, the
gateways are ports for the design. Here, the tool flow takes care of this.

Sincerely,

Mugundhan

On Tue, 11 Aug, 2020, 6:24 PM Heystek Grobler, 
wrote:

> Good day everyone
>
> I am compiling a design for Roach2. I can into this error when running
> casper_xps:
>
> "xilinx input gateways cannot be used in a design. Only gpio blocks”
>
> How can I solve this or am I doing something stupid?
>
> Thanks for the help
>
> Heystek
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/7A801B91-ED60-4D83-A14A-3B0B1D8D4E8E%40gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xnTExq63tyLj3P9-UM56Y9sL7z3t0ocvOx4GMSrW5sQJA%40mail.gmail.com.

Re: [casper] Writing data to SD card

[Mugundhan vijayaraghavan]

Hi Sean,

This help document says that the sd card is mounted as the read only /opt
file system.
https://redpitaya.readthedocs.io/en/latest/developerGuide/software/clt.html?highlight=store%20data#saving-data-buffers

Having said that, red-pitaya GPIOs provide access to SPI interfaces to the
PS side to connect a SD card and use that for data storage. This has been
done with Raspberry Pi. So, in principle, should be possible with the
RedPitaya as well.

Another option is to use an SPI implementation from the PL side, accessing
the GPIOs (there are about 16), if one is comfortable with using only hdl.

Sincerely,

Mugundhan




On Wed, May 20, 2020 at 8:55 PM Sean Mckee  wrote:

>  Hello all,
>
> I'm working on a project that has a Red Pitaya mounted in a drone. It will
> be monitoring and correlating two antenna inputs. Because the red pitaya
> will be in a drone, I need to store the processed data coming out of the
> FPGA onto the SD card. Is this something anyone has worked with in the
> Casper framework? I can't seem to find much documentation on accomplishing
> this. It seems like I might need to write some monitoring software for the
> programming system separately from the programming of the FPGA.
>
> I would like to achieve a continuous stream from the FPGA to the SD card
> of 2 megabytes/sec.
>
> Thanks for any insight you might have into this!
>
> -Sean
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/efcfb627-b710-4ba9-87d9-e92ec0c466cb%40lists.berkeley.edu
> 
> .
>


-- 
V. Mugundhan

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xkwqc5%3DVOU_YU1ydXUmZEwXsHNugJ5sqAbBnZvEvf5R%3Dg%40mail.gmail.com.

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hello Tavi,

There are implementations of red pitaya as a SDR by Pavel Demin, but the
max. bandwidth (that he has implemented) is about 2.5 MHz and also is
limited in tuning range.

Yes, using SDRs is another option. LimeSDR is a possible candidate which
gives tunability and max. instantaneous bandwidth of ~ 60 MHz. It also has
an Intel (Altera) FPGA, which people have tried to program to do some DSP
as well.

So this is a good suggestion.

Sincerely,

Mugundhan

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xnA8fo4sDZnzP%2BuvmO%2BbPahiau-xCOhEt%3DRdUV6tfsgiw%40mail.gmail.com.

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi Ross,

I agree with what you say.

At this point, if one is interested in only a single channel, then Dan's
idea of quadrature mixing can be tried out.
If one has to use mixers, rather than 60 MHz, depending on the filter's
roll off, one may have to settle for slightly smaller bandwidth.

Thanks,

Mugundhan

On Tue, Feb 11, 2020 at 7:37 AM Ross Martin  wrote:

> Hi Mugundhan,
>
> If you have a single stage mixer with an LO at 80MHz, it has the problem
> that the effective mixer signal may not be just a sine wave, but instead a
> sine wave with a tiny DC offset.
>
> If you have a DC offset that's X dB down from the sine wave amplitude, it
> will pass the original signal through at a level X dB down.  You need to be
> very careful that X is enough to provide the performance you desire,
> because the original signal is on top of your output signal and will
> interfere with it if it's not adequately attenuated.
>
> The mixer will also have distortion. That distortion will cause 2nd, 3rd,
> and higher-order effects, that need to be considered regarding what their
> amplitudes might be and in what frequency ranges they are.
>
> With more widely separated input and output frequencies for the mixer,
> it's easier to arrange that all these undesired mixer outputs are at
> frequencies that don't matter and can be rejected with lowpass or bandpass
> filters. In your case, a lot of these error terms will be right on top of
> your signal, and thus can't be rejected with a filter. That's probably not
> a problem if you only need 10dB, but if you want quality signals it should
> be analyzed carefully based on the specs of your mixer and your desired
> performance.  It may be that available mixers are really, really good, but
> it's something that should be checked carefully.
>
> Another issue with what you've proposed is that your output band goes all
> the way down to 0 Hertz. Mixers may produce a lot of noise near 0 Hertz,
> from squaring and quadratic distortion terms that effectively perform an AM
> detection on your entire input signal. Because of this noise, you probably
> don't want your signal going all the way down to zero Hertz, but instead
> have it bounded away from zero by some small amount with at least a DC
> rejection filter.  I'm not sure offhand how much separation might be
> enough.  This problem will also affect multi-stage mixers.  It may be that
> the mixer quality is good enough that this effect is small, but it should
> be checked carefully.
>
> Another issue you need to consider is that signals cannot cut off
> instantly in the frequency domain.  They must have tails that fade off
> gradually. And if you've got a sine wave at 1Hz, it's tails are most likely
> not going to fade off below desired levels by 0Hz.  Almost no analog
> filters are that good. Instead the tails will go past 0Hz into negative
> frequencies.  For real signals, negative frequencies fold back into
> positive frequencies and cause interference.  For this reason also, I
> believe your signal must be strictly bounded away from 0Hz.
>
> Regards,
>
> Ross
>
>
> On Mon, Feb 10, 2020, 8:26 AM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi Ross,
>>
>> Just to add, we can also have the lo at 80mhz, and use the lower side
>> band. 80 will be at 0, 20 will be at 60. But the band can be flipped
>> offline.  We can have a strong lpf at 60mhz, which can  cut the lo off
>> before downstream processing.
>>
>> Mugundhan
>>
>> On Mon, 10 Feb 2020, 15:18 Mugundhan vijayaraghavan, <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi Ross,
>>>
>>> I'm not working with Colm on this. So I don't know about the resources
>>> available to him.
>>>
>>> What you're saying is true. Doing it with a single stage may be
>>> problematic as with 20 MHz LO, the there will be overlap of the side bands.
>>> So, minimally, we need to have two stages. where the 20-80 MHz can be
>>> up-converted to outside the band and then down-converted into the base band
>>> of 0-60 MHz.
>>>
>>> Sorry for not being clear earlier.
>>>
>>> But anyway, for the RedPitaya, due to the sampling restrictions, 20-80
>>> MHz band has to be got into 0-60 MHz for getting the full band with the
>>> board.
>>>
>>> Thank you,
>>>
>>> Mugundhan
>>>
>>> On Mon, Feb 10, 2020 at 2:32 PM Ross Martin 
>>> wrote:
>>>
>>>> Hi Mugundhan,
>>>>
>>>> Could you say a little more about how you're downconverting 20-80MHz to
>>>> 0-60MHz?  My understanding is that this is not easy to

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi Ross,

Just to add, we can also have the lo at 80mhz, and use the lower side band.
80 will be at 0, 20 will be at 60. But the band can be flipped offline.  We
can have a strong lpf at 60mhz, which can  cut the lo off before downstream
processing.

Mugundhan

On Mon, 10 Feb 2020, 15:18 Mugundhan vijayaraghavan, <
v.vaishnav151...@gmail.com> wrote:

> Hi Ross,
>
> I'm not working with Colm on this. So I don't know about the resources
> available to him.
>
> What you're saying is true. Doing it with a single stage may be
> problematic as with 20 MHz LO, the there will be overlap of the side bands.
> So, minimally, we need to have two stages. where the 20-80 MHz can be
> up-converted to outside the band and then down-converted into the base band
> of 0-60 MHz.
>
> Sorry for not being clear earlier.
>
> But anyway, for the RedPitaya, due to the sampling restrictions, 20-80 MHz
> band has to be got into 0-60 MHz for getting the full band with the board.
>
> Thank you,
>
> Mugundhan
>
> On Mon, Feb 10, 2020 at 2:32 PM Ross Martin  wrote:
>
>> Hi Mugundhan,
>>
>> Could you say a little more about how you're downconverting 20-80MHz to
>> 0-60MHz?  My understanding is that this is not easy to do while retaining
>> signal quality.  The band overlap of the input and output bands means
>> simple conversion methods with normal mixers don't work.
>>
>> Ross
>>
>>
>> On Mon, Feb 10, 2020, 1:09 AM Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi jishnu,
>>>
>>> With red pitaya,  you have to down convert 20-80 to 0-60 baseband to use
>>> the band fully. As such, it has a cutoff at 65MHz.
>>>
>>> Thanks,
>>> Mugundhan
>>>
>>> On Mon, 10 Feb 2020, 13:30 Jishnu Nambissan T, 
>>> wrote:
>>>
>>>> Hi Mugundhan,
>>>>
>>>> With red pitaya, can you sample 20-80 MHz without downconversion ? And
>>>> if analog down conversion is required, wouldn't that restrict the usable
>>>> dynamic range (unless a high level mixer is used) ?
>>>>
>>>> Jishnu
>>>>
>>>> --
>>>> *From: *"Mugundhan vijayaraghavan" 
>>>> *To: *"casper" 
>>>> *Sent: *Thursday, February 6, 2020 1:06:09 AM
>>>> *Subject: *Re: [casper] Solar Spectrometer Channeliser
>>>>
>>>> Hi Dan,
>>>>
>>>> We have done integration times from 20ms upto a second. There are
>>>> bursts that last for hours, minutes and a few ms to seconds as well.
>>>>
>>>> We have not tried AGC on these bursts since we were aiming to study
>>>> them only. In the 8 bit design, we had 3 bits for background and remaining
>>>> 5 to accommodate bursts.
>>>>
>>>> The red pitaya can still be used if Colm can restrict the band to 20-80
>>>> mhz, because the ionosphere starts cutting of anything below 20mhz
>>>> mostly(depending on the location of course). Then this can be down
>>>> converted to fit into 0-62.5 mhz base band of the red pitaya.
>>>>
>>>> Thanks,
>>>>
>>>> Mugundhan
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 5 Feb 2020, 22:23 Dan Werthimer,  wrote:
>>>>
>>>>>
>>>>> hi mugundhan,
>>>>>
>>>>> what's the time scale for these bursts?
>>>>> rise and fall times?
>>>>> can you use a AGC circuit (automatic gain control),
>>>>> eg: computer controlled attenuator
>>>>> to turn down the power going into the ADC during the bursts,
>>>>> so you could keep the levels going into the ADC relatively constant?
>>>>> if the rise and fall times are longer than 1ms (the integration time
>>>>> of the spectrometer),
>>>>> then you could adjust the power level for each spectrum, and write
>>>>> down where
>>>>> you set the attenuator for that spectrum, so you could still know the
>>>>> absolute power.
>>>>>
>>>>> if not, there are some 14 bit 200 Msps ADC boards,  and i think the
>>>>> new RFSOC boards/chips have 14 bit ADC's,
>>>>> but you'll have to write a casper yellow interface block for this
>>>>> ADC,
>>>>> as we don't have a 14 bit 200 Msps ADC in the casper library.
>>>>>
>>>>> another possiblity is to multiplex your 80 M

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi Ross,

I'm not working with Colm on this. So I don't know about the resources
available to him.

What you're saying is true. Doing it with a single stage may be problematic
as with 20 MHz LO, the there will be overlap of the side bands. So,
minimally, we need to have two stages. where the 20-80 MHz can be
up-converted to outside the band and then down-converted into the base band
of 0-60 MHz.

Sorry for not being clear earlier.

But anyway, for the RedPitaya, due to the sampling restrictions, 20-80 MHz
band has to be got into 0-60 MHz for getting the full band with the board.

Thank you,

Mugundhan

On Mon, Feb 10, 2020 at 2:32 PM Ross Martin  wrote:

> Hi Mugundhan,
>
> Could you say a little more about how you're downconverting 20-80MHz to
> 0-60MHz?  My understanding is that this is not easy to do while retaining
> signal quality.  The band overlap of the input and output bands means
> simple conversion methods with normal mixers don't work.
>
> Ross
>
>
> On Mon, Feb 10, 2020, 1:09 AM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi jishnu,
>>
>> With red pitaya,  you have to down convert 20-80 to 0-60 baseband to use
>> the band fully. As such, it has a cutoff at 65MHz.
>>
>> Thanks,
>> Mugundhan
>>
>> On Mon, 10 Feb 2020, 13:30 Jishnu Nambissan T,  wrote:
>>
>>> Hi Mugundhan,
>>>
>>> With red pitaya, can you sample 20-80 MHz without downconversion ? And
>>> if analog down conversion is required, wouldn't that restrict the usable
>>> dynamic range (unless a high level mixer is used) ?
>>>
>>> Jishnu
>>>
>>> --
>>> *From: *"Mugundhan vijayaraghavan" 
>>> *To: *"casper" 
>>> *Sent: *Thursday, February 6, 2020 1:06:09 AM
>>> *Subject: *Re: [casper] Solar Spectrometer Channeliser
>>>
>>> Hi Dan,
>>>
>>> We have done integration times from 20ms upto a second. There are bursts
>>> that last for hours, minutes and a few ms to seconds as well.
>>>
>>> We have not tried AGC on these bursts since we were aiming to study them
>>> only. In the 8 bit design, we had 3 bits for background and remaining 5 to
>>> accommodate bursts.
>>>
>>> The red pitaya can still be used if Colm can restrict the band to 20-80
>>> mhz, because the ionosphere starts cutting of anything below 20mhz
>>> mostly(depending on the location of course). Then this can be down
>>> converted to fit into 0-62.5 mhz base band of the red pitaya.
>>>
>>> Thanks,
>>>
>>> Mugundhan
>>>
>>>
>>>
>>>
>>> On Wed, 5 Feb 2020, 22:23 Dan Werthimer,  wrote:
>>>
>>>>
>>>> hi mugundhan,
>>>>
>>>> what's the time scale for these bursts?
>>>> rise and fall times?
>>>> can you use a AGC circuit (automatic gain control),
>>>> eg: computer controlled attenuator
>>>> to turn down the power going into the ADC during the bursts,
>>>> so you could keep the levels going into the ADC relatively constant?
>>>> if the rise and fall times are longer than 1ms (the integration time of
>>>> the spectrometer),
>>>> then you could adjust the power level for each spectrum, and write down
>>>> where
>>>> you set the attenuator for that spectrum, so you could still know the
>>>> absolute power.
>>>>
>>>> if not, there are some 14 bit 200 Msps ADC boards,  and i think the new
>>>> RFSOC boards/chips have 14 bit ADC's,
>>>> but you'll have to write a casper yellow interface block for this ADC,
>>>> as we don't have a 14 bit 200 Msps ADC in the casper library.
>>>>
>>>> another possiblity is to multiplex your 80 MHz band, 40 MHz at a time
>>>> into a red pitaya board,
>>>> ping ponging back and forth between bands:  0 to 40 MHz for 1 ms, then
>>>> 40 to 80 MHz for the next ms.
>>>>
>>>>
>>>> best wishes,
>>>>
>>>> dan
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 5, 2020 at 8:33 AM Mugundhan vijayaraghavan <
>>>> v.vaishnav151...@gmail.com> wrote:
>>>>
>>>>> Hi Dan,
>>>>>
>>>>> Usually quiet sun doesn't show such abrupt changes, but bursts do
>>>>> (easily 40-50dB or more) for bright bursts. We have built 8 bit
>>>>> spectrometers in 40-80Mhz, but have found then when the bur

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Sorry Jishnu, I didn't see the mixer question.

If the mixer has a poorer dynamic range than the ADC, then the chain's DR
is limited by that. So, as far as the mixer's DR is better than a 14 bit
ADCs, it should be fine.

Mugundhan

On Mon, Feb 10, 2020 at 1:38 PM Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hi jishnu,
>
> With red pitaya,  you have to down convert 20-80 to 0-60 baseband to use
> the band fully. As such, it has a cutoff at 65MHz.
>
> Thanks,
> Mugundhan
>
> On Mon, 10 Feb 2020, 13:30 Jishnu Nambissan T,  wrote:
>
>> Hi Mugundhan,
>>
>> With red pitaya, can you sample 20-80 MHz without downconversion ? And if
>> analog down conversion is required, wouldn't that restrict the usable
>> dynamic range (unless a high level mixer is used) ?
>>
>> Jishnu
>>
>> --
>> *From: *"Mugundhan vijayaraghavan" 
>> *To: *"casper" 
>> *Sent: *Thursday, February 6, 2020 1:06:09 AM
>> *Subject: *Re: [casper] Solar Spectrometer Channeliser
>>
>> Hi Dan,
>>
>> We have done integration times from 20ms upto a second. There are bursts
>> that last for hours, minutes and a few ms to seconds as well.
>>
>> We have not tried AGC on these bursts since we were aiming to study them
>> only. In the 8 bit design, we had 3 bits for background and remaining 5 to
>> accommodate bursts.
>>
>> The red pitaya can still be used if Colm can restrict the band to 20-80
>> mhz, because the ionosphere starts cutting of anything below 20mhz
>> mostly(depending on the location of course). Then this can be down
>> converted to fit into 0-62.5 mhz base band of the red pitaya.
>>
>> Thanks,
>>
>> Mugundhan
>>
>>
>>
>>
>> On Wed, 5 Feb 2020, 22:23 Dan Werthimer,  wrote:
>>
>>>
>>> hi mugundhan,
>>>
>>> what's the time scale for these bursts?
>>> rise and fall times?
>>> can you use a AGC circuit (automatic gain control),
>>> eg: computer controlled attenuator
>>> to turn down the power going into the ADC during the bursts,
>>> so you could keep the levels going into the ADC relatively constant?
>>> if the rise and fall times are longer than 1ms (the integration time of
>>> the spectrometer),
>>> then you could adjust the power level for each spectrum, and write down
>>> where
>>> you set the attenuator for that spectrum, so you could still know the
>>> absolute power.
>>>
>>> if not, there are some 14 bit 200 Msps ADC boards,  and i think the new
>>> RFSOC boards/chips have 14 bit ADC's,
>>> but you'll have to write a casper yellow interface block for this ADC,
>>> as we don't have a 14 bit 200 Msps ADC in the casper library.
>>>
>>> another possiblity is to multiplex your 80 MHz band, 40 MHz at a time
>>> into a red pitaya board,
>>> ping ponging back and forth between bands:  0 to 40 MHz for 1 ms, then
>>> 40 to 80 MHz for the next ms.
>>>
>>>
>>> best wishes,
>>>
>>> dan
>>>
>>>
>>>
>>>
>>> On Wed, Feb 5, 2020 at 8:33 AM Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> Usually quiet sun doesn't show such abrupt changes, but bursts do
>>>> (easily 40-50dB or more) for bright bursts. We have built 8 bit
>>>> spectrometers in 40-80Mhz, but have found then when the burst is pretty
>>>> strong, saturation effects starts kicking in.
>>>>
>>>>
>>>> Thanks,
>>>> Mugundhan
>>>>
>>>>
>>>> On Wed, 5 Feb 2020, 21:52 Dan Werthimer,  wrote:
>>>>
>>>>>
>>>>> hi colm,
>>>>> regarding dynamic range
>>>>> -
>>>>> for your solar spectrometer, do you need 14 bits of ADC dynamic range?
>>>>> it's very unusual in radio astronomy to need that much instantaneous
>>>>> dynamic range on the input.
>>>>> does the sun vary on short time scales in the radio band by factor of
>>>>> 1000 in voltage (1,000,000 in power) ?
>>>>> or do you have very strong bursting RFI that is 1000 times the average
>>>>> noise voltage (1M in power) in the whole band?
>>>>>
>>>>> as you probably know, you'll have lots more dynamic range in the
>>>>> output power spectrum than the dynamic ran

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi jishnu,

With red pitaya,  you have to down convert 20-80 to 0-60 baseband to use
the band fully. As such, it has a cutoff at 65MHz.

Thanks,
Mugundhan

On Mon, 10 Feb 2020, 13:30 Jishnu Nambissan T,  wrote:

> Hi Mugundhan,
>
> With red pitaya, can you sample 20-80 MHz without downconversion ? And if
> analog down conversion is required, wouldn't that restrict the usable
> dynamic range (unless a high level mixer is used) ?
>
> Jishnu
>
> ------
> *From: *"Mugundhan vijayaraghavan" 
> *To: *"casper" 
> *Sent: *Thursday, February 6, 2020 1:06:09 AM
> *Subject: *Re: [casper] Solar Spectrometer Channeliser
>
> Hi Dan,
>
> We have done integration times from 20ms upto a second. There are bursts
> that last for hours, minutes and a few ms to seconds as well.
>
> We have not tried AGC on these bursts since we were aiming to study them
> only. In the 8 bit design, we had 3 bits for background and remaining 5 to
> accommodate bursts.
>
> The red pitaya can still be used if Colm can restrict the band to 20-80
> mhz, because the ionosphere starts cutting of anything below 20mhz
> mostly(depending on the location of course). Then this can be down
> converted to fit into 0-62.5 mhz base band of the red pitaya.
>
> Thanks,
>
> Mugundhan
>
>
>
>
> On Wed, 5 Feb 2020, 22:23 Dan Werthimer,  wrote:
>
>>
>> hi mugundhan,
>>
>> what's the time scale for these bursts?
>> rise and fall times?
>> can you use a AGC circuit (automatic gain control),
>> eg: computer controlled attenuator
>> to turn down the power going into the ADC during the bursts,
>> so you could keep the levels going into the ADC relatively constant?
>> if the rise and fall times are longer than 1ms (the integration time of
>> the spectrometer),
>> then you could adjust the power level for each spectrum, and write down
>> where
>> you set the attenuator for that spectrum, so you could still know the
>> absolute power.
>>
>> if not, there are some 14 bit 200 Msps ADC boards,  and i think the new
>> RFSOC boards/chips have 14 bit ADC's,
>> but you'll have to write a casper yellow interface block for this ADC,
>> as we don't have a 14 bit 200 Msps ADC in the casper library.
>>
>> another possiblity is to multiplex your 80 MHz band, 40 MHz at a time
>> into a red pitaya board,
>> ping ponging back and forth between bands:  0 to 40 MHz for 1 ms, then 40
>> to 80 MHz for the next ms.
>>
>>
>> best wishes,
>>
>> dan
>>
>>
>>
>>
>> On Wed, Feb 5, 2020 at 8:33 AM Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi Dan,
>>>
>>> Usually quiet sun doesn't show such abrupt changes, but bursts do
>>> (easily 40-50dB or more) for bright bursts. We have built 8 bit
>>> spectrometers in 40-80Mhz, but have found then when the burst is pretty
>>> strong, saturation effects starts kicking in.
>>>
>>>
>>> Thanks,
>>> Mugundhan
>>>
>>>
>>> On Wed, 5 Feb 2020, 21:52 Dan Werthimer,  wrote:
>>>
>>>>
>>>> hi colm,
>>>> regarding dynamic range
>>>> -
>>>> for your solar spectrometer, do you need 14 bits of ADC dynamic range?
>>>> it's very unusual in radio astronomy to need that much instantaneous
>>>> dynamic range on the input.
>>>> does the sun vary on short time scales in the radio band by factor of
>>>> 1000 in voltage (1,000,000 in power) ?
>>>> or do you have very strong bursting RFI that is 1000 times the average
>>>> noise voltage (1M in power) in the whole band?
>>>>
>>>> as you probably know, you'll have lots more dynamic range in the output
>>>> power spectrum than the dynamic range of the ADC:
>>>> if you are building a 1024 channel spectrometer with 1 ms integration,
>>>> you'll get about 8 bits more bits of dynamic range above your ADC
>>>> dynamic range in frequency domain voltage,
>>>> which is 16 bits more of dynamic range above your ADC dynamic range in
>>>> power spectra.
>>>> so you'll have about 20 bits of spectral dynamic range if you use an 8
>>>> bit ADC,
>>>> (power spectrum dynamic range of about 1 million in 1 ms with an 8 bit
>>>> ADC, setting noise at 3 bit RMS).
>>>> and 24 bits of spectrral dynamic range for a 10 bit ADC, 28 bits for 12
>>>> bit ADC, and 32 bits for for 14 bit ADC).
>>>>
&g

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi Dan,

We have done integration times from 20ms upto a second. There are bursts
that last for hours, minutes and a few ms to seconds as well.

We have not tried AGC on these bursts since we were aiming to study them
only. In the 8 bit design, we had 3 bits for background and remaining 5 to
accommodate bursts.

The red pitaya can still be used if Colm can restrict the band to 20-80
mhz, because the ionosphere starts cutting of anything below 20mhz
mostly(depending on the location of course). Then this can be down
converted to fit into 0-62.5 mhz base band of the red pitaya.

Thanks,

Mugundhan




On Wed, 5 Feb 2020, 22:23 Dan Werthimer,  wrote:

>
> hi mugundhan,
>
> what's the time scale for these bursts?
> rise and fall times?
> can you use a AGC circuit (automatic gain control),
> eg: computer controlled attenuator
> to turn down the power going into the ADC during the bursts,
> so you could keep the levels going into the ADC relatively constant?
> if the rise and fall times are longer than 1ms (the integration time of
> the spectrometer),
> then you could adjust the power level for each spectrum, and write down
> where
> you set the attenuator for that spectrum, so you could still know the
> absolute power.
>
> if not, there are some 14 bit 200 Msps ADC boards,  and i think the new
> RFSOC boards/chips have 14 bit ADC's,
> but you'll have to write a casper yellow interface block for this ADC,
> as we don't have a 14 bit 200 Msps ADC in the casper library.
>
> another possiblity is to multiplex your 80 MHz band, 40 MHz at a time into
> a red pitaya board,
> ping ponging back and forth between bands:  0 to 40 MHz for 1 ms, then 40
> to 80 MHz for the next ms.
>
>
> best wishes,
>
> dan
>
>
>
>
> On Wed, Feb 5, 2020 at 8:33 AM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi Dan,
>>
>> Usually quiet sun doesn't show such abrupt changes, but bursts do (easily
>> 40-50dB or more) for bright bursts. We have built 8 bit spectrometers in
>> 40-80Mhz, but have found then when the burst is pretty strong, saturation
>> effects starts kicking in.
>>
>>
>> Thanks,
>> Mugundhan
>>
>>
>> On Wed, 5 Feb 2020, 21:52 Dan Werthimer,  wrote:
>>
>>>
>>> hi colm,
>>>
>>> regarding dynamic range
>>> -
>>> for your solar spectrometer, do you need 14 bits of ADC dynamic range?
>>> it's very unusual in radio astronomy to need that much instantaneous
>>> dynamic range on the input.
>>> does the sun vary on short time scales in the radio band by factor of
>>> 1000 in voltage (1,000,000 in power) ?
>>> or do you have very strong bursting RFI that is 1000 times the average
>>> noise voltage (1M in power) in the whole band?
>>>
>>> as you probably know, you'll have lots more dynamic range in the output
>>> power spectrum than the dynamic range of the ADC:
>>> if you are building a 1024 channel spectrometer with 1 ms integration,
>>> you'll get about 8 bits more bits of dynamic range above your ADC
>>> dynamic range in frequency domain voltage,
>>> which is 16 bits more of dynamic range above your ADC dynamic range in
>>> power spectra.
>>> so you'll have about 20 bits of spectral dynamic range if you use an 8
>>> bit ADC,
>>> (power spectrum dynamic range of about 1 million in 1 ms with an 8 bit
>>> ADC, setting noise at 3 bit RMS).
>>> and 24 bits of spectrral dynamic range for a 10 bit ADC, 28 bits for 12
>>> bit ADC, and 32 bits for for 14 bit ADC).
>>>
>>> regarding boards for your spectrometer
>>> ---
>>>
>>> 1) as adam pointed out, the red pitaya is cheap, but sample rate and
>>> bandwidth don't quite get the specs you need.
>>>
>>> 2)  another possibility is to use a snap board, which costs more, but
>>> can sample 3 inputs at 950 Msps,
>>> or 6 inputs at 500 Msps, or 12 inputs at 250 Msps with 8 bit ADC's.
>>> most people populate the snap board with 8 bit ADCs,
>>> but a few people have populated it with 12 bit ADC's, although the
>>> sample rate goes down by 8/12.
>>>
>>> 3) another possibility is to use a xilinx RFSOC board.  the first gen
>>> has a bank of 12 bit ADC's  (8 inputs at 4 Gsps, or 16 inputs at 2 Gsps),
>>> but i think the new generation has 14 bit ADC's ?the RFSOC boards
>>> cost more than snaps, but RFSOC was designed
>>> in dublin, so you can probably get one from xilinx dublin   the
>>> 

Re: [casper] Solar Spectrometer Channeliser

[Mugundhan vijayaraghavan]

Hi Dan,

Usually quiet sun doesn't show such abrupt changes, but bursts do (easily
40-50dB or more) for bright bursts. We have built 8 bit spectrometers in
40-80Mhz, but have found then when the burst is pretty strong, saturation
effects starts kicking in.


Thanks,
Mugundhan


On Wed, 5 Feb 2020, 21:52 Dan Werthimer,  wrote:

>
> hi colm,
>
> regarding dynamic range
> -
> for your solar spectrometer, do you need 14 bits of ADC dynamic range?
> it's very unusual in radio astronomy to need that much instantaneous
> dynamic range on the input.
> does the sun vary on short time scales in the radio band by factor of 1000
> in voltage (1,000,000 in power) ?
> or do you have very strong bursting RFI that is 1000 times the average
> noise voltage (1M in power) in the whole band?
>
> as you probably know, you'll have lots more dynamic range in the output
> power spectrum than the dynamic range of the ADC:
> if you are building a 1024 channel spectrometer with 1 ms integration,
> you'll get about 8 bits more bits of dynamic range above your ADC dynamic
> range in frequency domain voltage,
> which is 16 bits more of dynamic range above your ADC dynamic range in
> power spectra.
> so you'll have about 20 bits of spectral dynamic range if you use an 8 bit
> ADC,
> (power spectrum dynamic range of about 1 million in 1 ms with an 8 bit
> ADC, setting noise at 3 bit RMS).
> and 24 bits of spectrral dynamic range for a 10 bit ADC, 28 bits for 12
> bit ADC, and 32 bits for for 14 bit ADC).
>
> regarding boards for your spectrometer
> ---
>
> 1) as adam pointed out, the red pitaya is cheap, but sample rate and
> bandwidth don't quite get the specs you need.
>
> 2)  another possibility is to use a snap board, which costs more, but can
> sample 3 inputs at 950 Msps,
> or 6 inputs at 500 Msps, or 12 inputs at 250 Msps with 8 bit ADC's.  most
> people populate the snap board with 8 bit ADCs,
> but a few people have populated it with 12 bit ADC's, although the sample
> rate goes down by 8/12.
>
> 3) another possibility is to use a xilinx RFSOC board.  the first gen has
> a bank of 12 bit ADC's  (8 inputs at 4 Gsps, or 16 inputs at 2 Gsps),
> but i think the new generation has 14 bit ADC's ?the RFSOC boards cost
> more than snaps, but RFSOC was designed
> in dublin, so you can probably get one from xilinx dublin   the ZCU111
> board has not been fully casperized yet though.
>
> best wishes,
>
> dan
>
>
>
>
>
> Dan Werthimer
> Marilyn and Watson Alberts Chair
> Astronomy Dept and Space Sciences Lab
> University of California, Berkeley
>
>
> On Wed, Feb 5, 2020 at 5:06 AM Colm Bracken  wrote:
>
>> Hello CASPER people,
>>
>> We are looking to build a spectrometer with not too demanding
>> requirements.
>> Based on the specs below, would the Red Pitaya be up to the job do you
>> think?
>> Or, is there another, better suited (but similarly affordable) solution?
>>
>> Chanel widths: ~< 100 kHz
>> Time sampling: ~< millisecond
>> Polarisation: 2 channels
>> Antenna freq range: 10-85 MHz (total bandwidth of 75 MHz)
>> Digitisation: 14 bit
>>
>> Any advice on this would be great!
>>
>> Thanks in advance,
>> Colm
>> --
>>
>> *Dr Colm Bracken*
>> Lecturer
>> Maynooth University Experimental Physics
>>
>>
>> Maynooth University, Maynooth, Co. Kildare, Ireland.
>>
>> T: +353 1 708 3641
>> E: colm.brac...@mu.ie W: www.maynoothuniversity.ie
>>
>> Follow my work on https://nuim.academia.edu/ColmBracken
>>
>>
>>
>> And
>>
>>
>> Research Associate
>>
>> Astronomy & Astrophysics Section
>> School of Cosmic Physics
>> Dublin Institute for Advanced Studies
>> 31 Fitzwilliam Place
>> Dublin 2, D02 XF86
>>
>>
>>
>> T: +353 1 440 6656 ext 352
>> E: cbrac...@cp.dias.ie W: www.dias.ie/2017/06/22/dr-colm-bracken
>>
>> Follow my work on https://nuim.academia.edu/ColmBracken
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAEx9wh8jNxeUnPGaSvwwuAtPCRsnNoCbOFnhbpU9EDb%2BPKh-Bg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAGHS_vH-6MvNUAxsZVs8KOW%2BUhOB5tUAZQdmu3_%3D9A24RL1Fqw%40mail.gmail.com
> 

Re: [casper] synchronization of cross ADC

[Mugundhan vijayaraghavan]

Another question. Are you using power dividing a single output of the Valon
and giving to both ADCs? When you do this you see correlation using noise
or cw in all four channels?

On Wed 27 Nov, 2019 09:16 'Nikita Rathore' via casper@lists.berkeley.edu, <
casper@lists.berkeley.edu> wrote:

> Dear Mugundhan,
>
> Many thanks for your reply.
>
> To answer your question, yes, the same sampling clock is given to both the
> ADCs from the same source (a Valon synthesizer).
>
> Could you please tell me how to use the 1pps signal to find the delay on
> the FPGA? The design has a coarse delay before the PFB block and fine
> delays after the FFT block.
>
> On Tue, Nov 26, 2019 at 6:35 PM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi Nikitha,
>>
>> Are the sampling clocks given to the adc from the same source? If you're
>> giving from a different source, please check if both are synchronised. Then
>> the 1pps signal can be independently be used to find the delay in the
>> electronics and can be corrected for using delay blocks on the FPGA.
>>
>> Regards,
>>
>> Mugundhan
>>
>> On Tue 26 Nov, 2019 13:25 'Nikita Rathore' via casper@lists.berkeley.edu,
>>  wrote:
>>
>>> Dear Casperites,
>>>
>>> I am trying to make a 4-element interferometer at L-band (bandwidth 300
>>> MHz) on a ROACH2 Board which has 2 x 5Gsps (ASIAA) ADC boards. I
>>> successfully compiled and tested a 2-element interferometer, through drift
>>> scans of the sun, and it yields fringes as expected.
>>>
>>> However, I have not been able to replicate these fringes with a
>>> 4-element design, so I started testing a 2-element correlator using two
>>> different ADCs on the same ROACH2. I was earlier using a software
>>> synchronization, as suggested in the tutorial.
>>>
>>> Could you please guide me on how to synchronize the two cross ADC of the
>>> same ROACH2 Board so they can be in sync with the FPGA clock (150MHz) which
>>> is taken from one of the ADC clocks (adc0 in my case). We have used two
>>> ADC1x5000-8 of the board for the experiment. We noticed the two sync port
>>> on the Board and as mentioned on the Casper site we had synchronized our
>>> ADC by 1pps signal and also by software. I have attached the results.
>>>
>>> My question is how to synchronize these two ADC by a pps signal and also
>>> do we need to synchronize the cross ADC of the same Board when working for
>>> correlator. In my case, I had the same results for synchronized and
>>> unsynchronized ADC.
>>>  Synchronization of two cross ADC
>>> <https://docs.google.com/a/iiti.ac.in/document/d/1fdzVWFTYx55IftxvvgSxvJfFk9x1Q89-Gum2iukoVpo/edit?usp=drive_web>
>>>
>>>
>>> --
>>> Nikita Rathore
>>> Junior Research Fellow
>>> Discipline of Astronomy, Astrophysics & Space Engineering (DAASE)
>>> Indian Institute of Technology, Indore
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAOvmUY5%3D9XcjrDBigY4Gz2TkxeCONcZA2dciTeRgE%3DVbeqBB0Q%40mail.gmail.com
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAOvmUY5%3D9XcjrDBigY4Gz2TkxeCONcZA2dciTeRgE%3DVbeqBB0Q%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xn0AkOn4%2B%2BcWo9jwhw1g5332kjMKhjh%3DA6967qq5ENU%2BQ%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xn0AkOn4%2B%2BcWo9jwhw1g5332kjMKhjh%3DA6967qq5ENU%2BQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Nikita Rathore
> Junior Research Fellow
> Discipline of Astronomy, Astrophysics & Space Engineering (DAASE)
> Indian Institute of Technology, Indore
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkel

Re: [casper] synchronization of cross ADC

[Mugundhan vijayaraghavan]

Hi Nikita,

For finding the delay, you can record the (same) 1pps input from both the
adc boards in a Bram and try to look at the delay in the rising edge
between them. To do it on the fly, have a free running counter, latch the
counter on the rising edge, and find the difference between the two counts,
which will give the delay in clock cycles.

Thanks,

Mugundhan

On Wed 27 Nov, 2019 09:16 'Nikita Rathore' via casper@lists.berkeley.edu, <
casper@lists.berkeley.edu> wrote:

> Dear Mugundhan,
>
> Many thanks for your reply.
>
> To answer your question, yes, the same sampling clock is given to both the
> ADCs from the same source (a Valon synthesizer).
>
> Could you please tell me how to use the 1pps signal to find the delay on
> the FPGA? The design has a coarse delay before the PFB block and fine
> delays after the FFT block.
>
> On Tue, Nov 26, 2019 at 6:35 PM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi Nikitha,
>>
>> Are the sampling clocks given to the adc from the same source? If you're
>> giving from a different source, please check if both are synchronised. Then
>> the 1pps signal can be independently be used to find the delay in the
>> electronics and can be corrected for using delay blocks on the FPGA.
>>
>> Regards,
>>
>> Mugundhan
>>
>> On Tue 26 Nov, 2019 13:25 'Nikita Rathore' via casper@lists.berkeley.edu,
>>  wrote:
>>
>>> Dear Casperites,
>>>
>>> I am trying to make a 4-element interferometer at L-band (bandwidth 300
>>> MHz) on a ROACH2 Board which has 2 x 5Gsps (ASIAA) ADC boards. I
>>> successfully compiled and tested a 2-element interferometer, through drift
>>> scans of the sun, and it yields fringes as expected.
>>>
>>> However, I have not been able to replicate these fringes with a
>>> 4-element design, so I started testing a 2-element correlator using two
>>> different ADCs on the same ROACH2. I was earlier using a software
>>> synchronization, as suggested in the tutorial.
>>>
>>> Could you please guide me on how to synchronize the two cross ADC of the
>>> same ROACH2 Board so they can be in sync with the FPGA clock (150MHz) which
>>> is taken from one of the ADC clocks (adc0 in my case). We have used two
>>> ADC1x5000-8 of the board for the experiment. We noticed the two sync port
>>> on the Board and as mentioned on the Casper site we had synchronized our
>>> ADC by 1pps signal and also by software. I have attached the results.
>>>
>>> My question is how to synchronize these two ADC by a pps signal and also
>>> do we need to synchronize the cross ADC of the same Board when working for
>>> correlator. In my case, I had the same results for synchronized and
>>> unsynchronized ADC.
>>>  Synchronization of two cross ADC
>>> <https://docs.google.com/a/iiti.ac.in/document/d/1fdzVWFTYx55IftxvvgSxvJfFk9x1Q89-Gum2iukoVpo/edit?usp=drive_web>
>>>
>>>
>>> --
>>> Nikita Rathore
>>> Junior Research Fellow
>>> Discipline of Astronomy, Astrophysics & Space Engineering (DAASE)
>>> Indian Institute of Technology, Indore
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAOvmUY5%3D9XcjrDBigY4Gz2TkxeCONcZA2dciTeRgE%3DVbeqBB0Q%40mail.gmail.com
>>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAOvmUY5%3D9XcjrDBigY4Gz2TkxeCONcZA2dciTeRgE%3DVbeqBB0Q%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xn0AkOn4%2B%2BcWo9jwhw1g5332kjMKhjh%3DA6967qq5ENU%2BQ%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xn0AkOn4%2B%2BcWo9jwhw1g5332kjMKhjh%3DA6967qq5ENU%2BQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Nikita Rathore
> Junior Research Fellow
> Discipline of Astronomy, Astrophysics & S

Re: [casper] synchronization of cross ADC

[Mugundhan vijayaraghavan]

Hi Nikitha,

Are the sampling clocks given to the adc from the same source? If you're
giving from a different source, please check if both are synchronised. Then
the 1pps signal can be independently be used to find the delay in the
electronics and can be corrected for using delay blocks on the FPGA.

Regards,

Mugundhan

On Tue 26 Nov, 2019 13:25 'Nikita Rathore' via casper@lists.berkeley.edu, <
casper@lists.berkeley.edu> wrote:

> Dear Casperites,
>
> I am trying to make a 4-element interferometer at L-band (bandwidth 300
> MHz) on a ROACH2 Board which has 2 x 5Gsps (ASIAA) ADC boards. I
> successfully compiled and tested a 2-element interferometer, through drift
> scans of the sun, and it yields fringes as expected.
>
> However, I have not been able to replicate these fringes with a 4-element
> design, so I started testing a 2-element correlator using two different
> ADCs on the same ROACH2. I was earlier using a software synchronization, as
> suggested in the tutorial.
>
> Could you please guide me on how to synchronize the two cross ADC of the
> same ROACH2 Board so they can be in sync with the FPGA clock (150MHz) which
> is taken from one of the ADC clocks (adc0 in my case). We have used two
> ADC1x5000-8 of the board for the experiment. We noticed the two sync port
> on the Board and as mentioned on the Casper site we had synchronized our
> ADC by 1pps signal and also by software. I have attached the results.
>
> My question is how to synchronize these two ADC by a pps signal and also
> do we need to synchronize the cross ADC of the same Board when working for
> correlator. In my case, I had the same results for synchronized and
> unsynchronized ADC.
>  Synchronization of two cross ADC
> 
>
>
> --
> Nikita Rathore
> Junior Research Fellow
> Discipline of Astronomy, Astrophysics & Space Engineering (DAASE)
> Indian Institute of Technology, Indore
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAOvmUY5%3D9XcjrDBigY4Gz2TkxeCONcZA2dciTeRgE%3DVbeqBB0Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560xn0AkOn4%2B%2BcWo9jwhw1g5332kjMKhjh%3DA6967qq5ENU%2BQ%40mail.gmail.com.

Re: [casper] Red Pitaya Autocorrelation spectrometer using casper biplex FFT

[Mugundhan vijayaraghavan]

Dear Dan,

Thanks for this input. I didn't think of that!
I'll run further tests and check the results.

Thanks,
Regards,
Mugundhan

On Sun 8 Sep, 2019 23:08 Dan Werthimer,  wrote:

>
>
> dear v. mugandhan,
>
> as you probably know, measuring the spectrum of an adc by terminating it's
> input or leaving it open is not very useful:
> adc's have a DC offset that changes with temperature.
> if the DC offset happens to be near an edge between two ADC staircase
> levels, the adc will chatter like crazy between these two levels,
> even a few microvolts of noise or RFI will cause the ADC to chatter
> between two or three levels, and the spectrum will be dominated
> by interleave spurs and RFI.  when the offset drifts so it's right between
> two levels, the spectral spurs and RFI will be smaller...
> if you add a few LSB of noise or signal, then the pattern is not dependent
> on the DC offset.
>
> best wishes,
>
> dan
>
>
>
>
> Dan Werthimer
> Marilyn and Watson Alberts Chair
> Astronomy Dept and Space Sciences Lab
> University of California, Berkeley
>
>
> On Fri, Sep 6, 2019 at 9:51 PM Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hello,
>>
>> Since there is an interest here in red pitaya based designs, I present
>> here one of my recent trials with the board. I was able to implement a
>> single channel autocorrelation spectrometer with a 4096 point (2048
>> positive frequency channels) in the red pitaya (125-14) using a combination
>> of the casper signal processing blocks and some HDL. The design is as
>> follows:
>>
>> The ADC data is converted to 2s complement, and this is input to a
>> simulink ip block, instantiated in the vivado block design. In simulink,
>> the ADC data is polyphase filtered and FFT'd to 4096 points and the FFT
>> spectra is accumulated for 4096 (fixed as of now) times, giving an
>> effective integration time of ~ 130 ms. The accumulated spectrum and the
>> respective data valid is the output of the simulink block. This is then
>> generated as an IP repository for the Zynq-7010 FPGA, and is imported as an
>> IP to the block design. The data from the spectrometer block is recast as a
>> 64 bit word (two spectral points concatenated) using the AXI DWIDTH
>> converter block and the data is written into a BRAM using Demin's BRAM
>> writer block. There is a status signal which informs the BRAM that the
>> samples have been written into the former, and then the PS starts reading
>> this BRAM as a memory mapped IP, using Pavel Demin's BRAM reader core. The
>> c program needed for the control of the spectrometer is executed in the
>> linux running on the RP's PS.
>>
>> I carried out a preliminary testing using noise signals (attached sample
>> spectra). I find that in the spectrum there are spurs at fs/4+/-fs/8,
>> fs/4+/-fs/16 and so on, which show up when using a 50 ohm termination at
>> the ADC input or keeping the input open. When providing a noise signal of ~
>> -30dBm strength, these spurs disappear, suggesting they are additive in
>> nature. I'm investigating the spurs presently !
>>
>> Attached with this mail is the github repo that contains the vivado
>> project tcls, block diagram files, the slx files for the simulink design
>> and the C code for the control and acquisition. I'd be glad if people in
>> the community use this and see if they are able to get similar or better
>> results ! I'm also working on porting the design to a 2 channel PoCo like
>> design, which I'll share here once the preliminary tests are done.
>>
>> github link: https://github.com/mugundhan1/rp_fft_spectrometer.git
>>
>> Note: Please include pavel demin's bram axis writer and bram axi reader
>> ips to the IP repo path in vivado (from
>> https://github.com/pavel-demin/red-pitaya-notes/tree/master/cores). I
>> have not uploaded all the files generated by vivado itself as the repo size
>> becomes close to a GB then. Any feedback is definitely appreciated !
>>
>>
>> --
>> V. Mugundhan
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560x%3DaCXKWW5M3ypsHmARDfHrGqW-JMWFDQTSv2Fqc22FFHA%40mail.gmail.com
>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAD560x%3DaCXKWW5M3ypsHmARDfHrGqW-JMWFDQTSv2Fqc

Re: [casper] casperites receive breakthough prize

[Mugundhan vijayaraghavan]

Very hearty congratulations!
Best wishes. Hope you guys convert this to a hat-trick!

Regards,
Mugundhan


On Thu 5 Sep, 2019 21:36 Dan Werthimer,  wrote:

>
> casperites,
>
> several casper people received the breakthrough prize today for making the
> first image of a black hole,
> including jonathan weintroub, homin jiang, nimish patel, matt dexter,
> arash roshanineshat, laura vertaschitsch, and casper co-founder mel wright.
> the $3M prize is divided equally by the 347 member event horizon telescope
> team listed below, so our fellow casperite's aren't rich.
>
> details at  https://breakthroughprize.org/News/54
>
> dan
>
>
>
> Kazunori Akiyama, Antxon Alberdi, Walter Alef, Juan-Carlos Algaba,
> Alexander Allardi, Rodrigo Amestica, Jadyn Anczarski, Keiichi Asada,
> Rebecca Azulay, Uwe Bach, Anne-Kathrin Baczko, Frederick K. Baganoff, David
> Ball, Mislav Baloković, John Barrett, Christopher Beaudoin, Bradford A.
> Benson, Ryan Berthold, Dan Bintley, Lindy Blackburn, Jay M. Blanchard, Ray
> Blundell, Wilfred Boland, Katherine L. Bouman, Geoffrey C. Bower, Michael
> Bremer, Christiaan D. Brinkerink, Roger Brissenden, Silke Britzen, Avery E.
> Broderick, Dominique Broguiere, Thomas Bronzwaer, Sandra Bustamente,
> Do-Young Byun, Roger Cappallo, John E. Carlstrom, Edgar Castillo-Domínguez,
> Andrew Chael, Chi-kwan Chan, Chih-Cheng Chang, Shu-Hao Chang, Song-Chu
> Chang, Shami Chatterjee, Koushik Chatterjee, Ming-Tang Chen, Chung-Chen
> Chen, Yongjun Chen (陈永军), Ryan Chilson, Ilje Cho, Pierre Christian, Tim C.
> Chuter, John E. Conway, James M. Cordes, Rodrigo Córdova Rosado, Iain M.
> Coulson, Thomas M. Crawford, Geoffrey B. Crew, Joseph Crowley, Yuzhu Cui,
> Jordy Davelaar, John David, Mariafelicia De Laurentis, Roger Deane, Jessica
> Dempsey, Mark Derome, Gregory Desvignes, Jason Dexter, Matthew Dexter,
> Sheperd S. Doeleman, Sven Dornbusch, Sergio A. Dzib, Ralph P. Eatough,
> Andreas Eckart, Chris Eckert, Neal R. Erickson, Wendeline B. Everett, Aaron
> Faber, Heino Falcke, Joseph R. Farah, Vernon Fath, Vincent L. Fish, Thomas
> W. Folkers, Ed Fomalont, David C. Forbes, Raquel Fraga-Encinas, William T.
> Freeman, Robert Freund, Per Friberg, Christian M. Fromm, David M. Gale,
> Peter Galison, Charles F. Gammie, Feng Gao, Roberto García, Gertie
> Geertsema, Olivier Gentaz, Boris Georgiev, Ciriaco Goddi, Roman Gold, José
> L. Gómez, Arturo I. Gómez-Ruiz, David A. Graham, Christopher H. Greer,
> Ronald Grosslein, Minfeng Gu(顾敏峰), Frédéric Gueth, Mark Gurwell, Kazuhiro
> Hada, Daryl Haggard, Nils W. Halverson, Chih-Chiang Han, Kuo-Chang Han,
> Jinchi Hao, Yutaka Hasegawa, Michael H. Hecht, Jason W. Henning, Antonio
> Hernández-Gómez, Rubén Herrero-Illana, Ronald Hesper, Stefan Heyminck,
> Akihiko Hirota, Paul Ho, Luis C. Ho (何子山), James Hoge, Mareki Honma,
> Chih-Wei L. Huang, Yau-De Huang, Lei Huang (黄磊), David H. Hughes, Shiro
> Ikeda, C. M. Violette Impellizzeri, Makoto Inoue, Sara Issaoun, David J.
> James, Huib Jan van Langevelde, Buell T. Jannuzi, Michael Janssen, Britton
> Jeter, Homin Jiang, Wu Jiang (江悟), Michael D. Johnson, Svetlana Jorstad,
> Taehyun Jung, Atish Kamble, Mansour Karami, Ramesh Karuppusamy, Tomohisa
> Kawashima, Garrett K. Keating, Ryan Keisler, Mark Kettenis, Jae-Young Kim,
> Junhan Kim, Jongsoo Kim, Kimihiro Kimura, Motoki Kino, Patrick M. Koch,
> Yusuke Kono, Shoko Koyama, Michael Kramer, Carsten Kramer, Thomas P.
> Krichbaum, Derek Kubo, Cheng-Yu Kuo, John Kuroda, Richard Lacasse, Robert
> A. Laing, Tod R. Lauer, Sang-Sung Lee, Erik M. Leitch, Chao-Te Li, Yan-Rong
> Li (李彦荣), Zhiyuan Li (李志远), Lupin C.-C. Lin, Michael Lindqvist, Kuo Liu,
> Ching-Tang Liu, Kuan-Yu Liu, Elisabetta Liuzzo, Wen-Ping Lo, Andrei P.
> Lobanov, Laurent Loinard, Colin Lonsdale, Li-Ming Lu, Ru-Sen Lu (路如森),
> Nicholas R. MacDonald, Jirong Mao (毛基荣), Sera Markoff, Daniel P. Marrone,
> Alan P. Marscher, Ralph G. Marson, Pierre L. Martin-Cocher, Iván
> Martí-Vidal, Kyle D. Massingill, Satoki Matsushita, Lynn D. Matthews,
> Callie Matulonis, Martin P. McColl, Stephen R. McWhirter, Lia Medeiros,
> Karl M. Menten, Hugo Messias, Zheng Meyer-Zhao, Daniel Michalik, Yosuke
> Mizuno, Izumi Mizuno, Alfredo Montaña, William Montgomerie, Matias
> Mora-Klein, James M. Moran, Kotaro Moriyama, Monika Moscibrodzka, Dirk
> Muders, Cornelia Müller, Andrew Nadolski, Hiroshi Nagai, Neil M. Nagar,
> Masanori Nakamura, Ramesh Narayan, Gopal Narayanan, Iniyan Natarajan,
> Santiago Navarro, Joseph Neilsen, Roberto Neri, Chi H. Nguyen, Chunchong
> Ni, Hiroaki Nishioka, Timothy Norton, Aristeidis Noutsos, Michael A. Nowak,
> George Nystrom, Hideo Ogawa, Hiroki Okino, Héctor Olivares, Gisela N.
> Ortiz-León, Peter Oshiro, Tomoaki Oyama, Feryal Özel, Stephen Padin, Scott
> N. Paine, Daniel C. M. Palumbo, Harriet Parsons, Nimesh Patel, Ue-Li Pen,
> Juan Peñalver, Dominic W. Pesce, Neil M. Phillips, Vincent Piétu, Richard
> Plambeck, Michael Poirier, Aleksandar Popstefanija, Oliver Porth, Nicolas
> Pradel, Ben Prather, Jorge A. 

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

Hi Jack,

The bof was not a executable, and this seemed to be the problem.
Once I changed it to an executable, then the ROACH got programmed.

Thank to you and James :)

Regards,

Mugundhan

On Fri, Oct 13, 2017 at 10:34 AM, Jack Hickish <jackhick...@gmail.com>
wrote:

> Hi Mugundhan,
>
> Is the boffile that fails to program executable? I.e., if you log into the
> roach and run "ls -la /boffiles/" do the working and not-working boffiles
> have the asme permissions.
> (I don't actually know if roach1 still requires boffiles to be executable,
> but it used to, so maybe it's worth checking).
>
> Cheers
> Jack
>
> On Thu, 12 Oct 2017 at 20:58 Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hi James,
>>
>> I tried it using the version of casperfpga you suggested. The same error
>> is returned.
>>
>> I'm attaching the python code that I'm using for programming the board.
>>
>> -
>> Regards,
>>
>> Mugundhan V.
>>
>> On Thu, Oct 12, 2017 at 5:24 PM, James Smith <jsm...@ska.ac.za> wrote:
>>
>>> Hello Mugundhan,
>>>
>>> Casperfpga is a work in progress and unfortunately some of the more
>>> recent developments will have broken compatibility with ROACH1. Its main
>>> focus at the moment is SKARAB / ROACH2.
>>>
>>> I use the following commit to work on ROACH1:
>>> avnuser@planck:~/SKASoftware/casperfpga$ git show
>>> commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
>>> Merge: 9835009 7402b29
>>> Author: Paul Prozesky <pa...@ska.ac.za>
>>> Date:   Fri Mar 4 17:27:09 2016 +0200
>>>
>>> Merge branch 'devel' of github.com:ska-sa/casperfpga into devel
>>>
>>> Try installing casperfpga from that particular git commit and you'll
>>> likely be more successful.
>>>
>>> Also, before you use the fpga.program() function, you need to set the
>>> bof file in the system information - I think I have mentioned how to do
>>> this in the history of the mailing list somewhere before.
>>>
>>> Let me know if it works.
>>>
>>> Regards,
>>> James
>>>
>>>
>>> On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
>>>> And I'm using the latest version of casperfpga library and katcp
>>>> version.
>>>>
>>>> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
>>>> v.vaishnav151...@gmail.com> wrote:
>>>>
>>>>> Hello James,
>>>>>
>>>>> I'm attaching the model files of the first and the second designs,
>>>>> along with the bof and the fga files. I used the ipython terminal for
>>>>> programming the fpga in both cases. The error I obtained is attached in a
>>>>> text file.
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Mugundhan V.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 12, 2017 at 3:49 PM, James Smith <jsm...@ska.ac.za> wrote:
>>>>>
>>>>>> Hello Mugundhan,
>>>>>>
>>>>>> Please describe your context a bit more - what libraries are you
>>>>>> using? Please also paste the error that you get? (and perhaps the code 
>>>>>> you
>>>>>> used to generate the error.)
>>>>>>
>>>>>> Regards,
>>>>>> James
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>>>>>> v.vaishnav151...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm facing a strange problem. I have an iADC, which I've connected
>>>>>>> to roach1 and have compiled a program to acquire raw samples from it. 
>>>>>>> The
>>>>>>> simulation, compilation and generation works fine and I get the bof and 
>>>>>>> the
>>>>>>> fpg files, which i place in their respective locations, and the ROACH 
>>>>>>> gets
>>>>>>> programmed well.
>>>>>>>
>>>>>>> I also developed a iADC spectropolarimeter and generated the fpg and
>>>>>>> bof files and placed them in their locations, but now when I try

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

Hi James,

I tried it using the version of casperfpga you suggested. The same error is
returned.

I'm attaching the python code that I'm using for programming the board.

-
Regards,

Mugundhan V.

On Thu, Oct 12, 2017 at 5:24 PM, James Smith <jsm...@ska.ac.za> wrote:

> Hello Mugundhan,
>
> Casperfpga is a work in progress and unfortunately some of the more recent
> developments will have broken compatibility with ROACH1. Its main focus at
> the moment is SKARAB / ROACH2.
>
> I use the following commit to work on ROACH1:
> avnuser@planck:~/SKASoftware/casperfpga$ git show
> commit 475ed6826b893230d62da8c7dcdcc2541bea83cf
> Merge: 9835009 7402b29
> Author: Paul Prozesky <pa...@ska.ac.za>
> Date:   Fri Mar 4 17:27:09 2016 +0200
>
> Merge branch 'devel' of github.com:ska-sa/casperfpga into devel
>
> Try installing casperfpga from that particular git commit and you'll
> likely be more successful.
>
> Also, before you use the fpga.program() function, you need to set the bof
> file in the system information - I think I have mentioned how to do this in
> the history of the mailing list somewhere before.
>
> Let me know if it works.
>
> Regards,
> James
>
>
> On Thu, Oct 12, 2017 at 12:35 PM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> And I'm using the latest version of casperfpga library and katcp version.
>>
>> On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hello James,
>>>
>>> I'm attaching the model files of the first and the second designs, along
>>> with the bof and the fga files. I used the ipython terminal for programming
>>> the fpga in both cases. The error I obtained is attached in a text file.
>>>
>>> Hope this helps,
>>>
>>> Thank you,
>>>
>>> Mugundhan V.
>>>
>>>
>>>
>>> On Thu, Oct 12, 2017 at 3:49 PM, James Smith <jsm...@ska.ac.za> wrote:
>>>
>>>> Hello Mugundhan,
>>>>
>>>> Please describe your context a bit more - what libraries are you using?
>>>> Please also paste the error that you get? (and perhaps the code you used to
>>>> generate the error.)
>>>>
>>>> Regards,
>>>> James
>>>>
>>>>
>>>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>>>> v.vaishnav151...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm facing a strange problem. I have an iADC, which I've connected to
>>>>> roach1 and have compiled a program to acquire raw samples from it. The
>>>>> simulation, compilation and generation works fine and I get the bof and 
>>>>> the
>>>>> fpg files, which i place in their respective locations, and the ROACH gets
>>>>> programmed well.
>>>>>
>>>>> I also developed a iADC spectropolarimeter and generated the fpg and
>>>>> bof files and placed them in their locations, but now when I try
>>>>> programming the ROACH, i get Katcp request time out error. If i reprogram
>>>>> the first bof file, it works fine, but repeated compilation and program
>>>>> cycles have failed for hte second model, with the same katcp request 
>>>>> failed
>>>>> error.
>>>>>
>>>>> Can someone kindly guide me solving it ?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> --
>>>>> V. Mugundhan
>>>>> SRF, IIA
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "casper@lists.berkeley.edu" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "casper@lists.berkeley.edu" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>>
>>>
>>>
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>
>

Re: [casper] ROACH1 Programming issues

[Mugundhan vijayaraghavan]

And I'm using the latest version of casperfpga library and katcp version.

On Thu, Oct 12, 2017 at 3:56 PM, Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hello James,
>
> I'm attaching the model files of the first and the second designs, along
> with the bof and the fga files. I used the ipython terminal for programming
> the fpga in both cases. The error I obtained is attached in a text file.
>
> Hope this helps,
>
> Thank you,
>
> Mugundhan V.
>
>
>
> On Thu, Oct 12, 2017 at 3:49 PM, James Smith <jsm...@ska.ac.za> wrote:
>
>> Hello Mugundhan,
>>
>> Please describe your context a bit more - what libraries are you using?
>> Please also paste the error that you get? (and perhaps the code you used to
>> generate the error.)
>>
>> Regards,
>> James
>>
>>
>> On Thu, Oct 12, 2017 at 12:17 PM, Mugundhan vijayaraghavan <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm facing a strange problem. I have an iADC, which I've connected to
>>> roach1 and have compiled a program to acquire raw samples from it. The
>>> simulation, compilation and generation works fine and I get the bof and the
>>> fpg files, which i place in their respective locations, and the ROACH gets
>>> programmed well.
>>>
>>> I also developed a iADC spectropolarimeter and generated the fpg and bof
>>> files and placed them in their locations, but now when I try programming
>>> the ROACH, i get Katcp request time out error. If i reprogram the first bof
>>> file, it works fine, but repeated compilation and program cycles have
>>> failed for hte second model, with the same katcp request failed error.
>>>
>>> Can someone kindly guide me solving it ?
>>>
>>> Thank you,
>>>
>>> --
>>> V. Mugundhan
>>> SRF, IIA
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "casper@lists.berkeley.edu" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to casper+unsubscr...@lists.berkeley.edu.
>>> To post to this group, send email to casper@lists.berkeley.edu.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
>
> --
> V. Mugundhan
> SRF, IIA
>



-- 
V. Mugundhan
SRF, IIA

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Re: [casper] Sysgen compilation error

[Mugundhan vijayaraghavan]

Hello again,

I have the latest ska-sa mlib devel installed. With this, I'm able to
compile the model file and the bof files are created. There is also a new
file with the format .fpg created. During my previous compilation cycle,
with older mlib-devel, (probably june 2015 version) the .fpg file is not
created. Secondly, if I burn the bof file created with the new mlib-devel
using progdev() function, the roach 1 is not getting programmed. Can
someone guide me as to what am I missing here ? and also, what is the .fpg
file ? what is it used for ?

Thank you,

Mugundhan

On Thu, Feb 11, 2016 at 8:06 PM, Mugundhan vijayaraghavan <
v.vaishnav151...@gmail.com> wrote:

> Hello Wesley, James,
>
> It was an issue with the shell scripting in ubuntu only. once I changed
> dash to bash, things started working !
>
> Thanks to you guys :)
>
> On Thu, Feb 11, 2016 at 4:35 PM, Wesley New <wes...@ska.ac.za> wrote:
>
>> This is an issue with dash in ubuntu, if you change your shell from dash
>> to bash it interprets the perl scripts properly.
>>
>> Have you followed these steps when setting up your tools flow?
>> https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b
>>
>> Particularly this step:
>>
>> The syntax in the Xilinx Perl scripts is not supported under the Ubuntu
>> default shell Dash. Change the symbolic link sh -> dash to sh -> bash:
>>
>>- cd /bin/
>>- sudo rm sh
>>- sudo ln -s bash sh
>>
>>
>> Wesley New
>> South African SKA Project
>> +2721 506 7300
>> www.ska.ac.za
>>
>>
>>
>> On Thu, Feb 11, 2016 at 12:58 PM, James Smith <jsm...@ska.ac.za> wrote:
>>
>>> Haven't encountered that specific issue before but I see a capital
>>> letter in your path. That may be an issue.
>>> On 11 Feb 2016 12:44, "Mugundhan vijayaraghavan" <
>>> v.vaishnav151...@gmail.com> wrote:
>>>
>>>> Hello guys,
>>>>
>>>> I'm running matlab/xilinx and mssge tools on a ubuntu 14.04 system.
>>>> When I do casper_xps and start compiling, I get this strange error.
>>>>
>>>> standard exception: XNetlistEngine:
>>>> Exception message could not be parsed:
>>>> com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass
>>>> text file at
>>>> /home/mugundhan/casper_designs/tut1/sysgen/sysgen/masterScript3888976111602024584.pl
>>>> line 559'
>>>>
>>>>
>>>> Reported by:
>>>> Unspecified
>>>>
>>>> Has anyone got this before ?
>>>>
>>>> Is there any workaround ?
>>>>
>>>>
>>>> --
>>>> the giver of moksha
>>>>
>>>
>>
>
>
> --
> the giver of moksha
>

Re: [casper] Sysgen compilation error

[Mugundhan vijayaraghavan]

Hello Wesley, James,

It was an issue with the shell scripting in ubuntu only. once I changed
dash to bash, things started working !

Thanks to you guys :)

On Thu, Feb 11, 2016 at 4:35 PM, Wesley New <wes...@ska.ac.za> wrote:

> This is an issue with dash in ubuntu, if you change your shell from dash
> to bash it interprets the perl scripts properly.
>
> Have you followed these steps when setting up your tools flow?
> https://casper.berkeley.edu/wiki/MSSGE_Setup_with_Xilinx_14.x_and_Matlab_2012b
>
> Particularly this step:
>
> The syntax in the Xilinx Perl scripts is not supported under the Ubuntu
> default shell Dash. Change the symbolic link sh -> dash to sh -> bash:
>
>- cd /bin/
>- sudo rm sh
>- sudo ln -s bash sh
>
>
> Wesley New
> South African SKA Project
> +2721 506 7300
> www.ska.ac.za
>
>
>
> On Thu, Feb 11, 2016 at 12:58 PM, James Smith <jsm...@ska.ac.za> wrote:
>
>> Haven't encountered that specific issue before but I see a capital letter
>> in your path. That may be an issue.
>> On 11 Feb 2016 12:44, "Mugundhan vijayaraghavan" <
>> v.vaishnav151...@gmail.com> wrote:
>>
>>> Hello guys,
>>>
>>> I'm running matlab/xilinx and mssge tools on a ubuntu 14.04 system. When
>>> I do casper_xps and start compiling, I get this strange error.
>>>
>>> standard exception: XNetlistEngine:
>>> Exception message could not be parsed:
>>> com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
>>> file at
>>> /home/mugundhan/casper_designs/tut1/sysgen/sysgen/masterScript3888976111602024584.pl
>>> line 559'
>>>
>>>
>>> Reported by:
>>> Unspecified
>>>
>>> Has anyone got this before ?
>>>
>>> Is there any workaround ?
>>>
>>>
>>> --
>>> the giver of moksha
>>>
>>
>


-- 
the giver of moksha

[casper] Sysgen compilation error

[Mugundhan vijayaraghavan]

Hello guys,

I'm running matlab/xilinx and mssge tools on a ubuntu 14.04 system. When I
do casper_xps and start compiling, I get this strange error.

standard exception: XNetlistEngine:
Exception message could not be parsed:
com.xilinx.sysgen.netlist.NetlistInternal: couldn't open first pass text
file at
/home/mugundhan/casper_designs/tut1/sysgen/sysgen/masterScript3888976111602024584.pl
line 559'


Reported by:
Unspecified

Has anyone got this before ?

Is there any workaround ?


-- 
the giver of moksha

Re: [casper] casper Digest, Vol 98, Issue 13

[Mugundhan vijayaraghavan]

Hello Amit, Andrew,

Can you elaborate what was the error in the PFB Generic block ? Was there
ringing ? because I had found ringing in the channel outputs recently when
using multi-channel PFB block (see an earlier conv. opened under "PFB
Ringing".

Thank you,


On Fri, Jan 22, 2016 at 1:39 AM,  wrote:

> Send casper mailing list submissions to
> casper@lists.berkeley.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu
>
> or, via email, send a message with subject or body 'help' to
> casper-requ...@lists.berkeley.edu
>
> You can reach the person managing the list at
> casper-ow...@lists.berkeley.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of casper digest..."
>
>
> Today's Topics:
>
>1. Re: Weird FFT Output (Amit Bansod)
>2. Re: Weird FFT Output (Andrew Martens)
>
>
> --
>
> Message: 1
> Date: Thu, 21 Jan 2016 10:18:19 +0100
> From: Amit Bansod 
> Subject: Re: [casper] Weird FFT Output
> To: Jack Hickish ,   casper list
> 
> Message-ID: <56a0a25b.5080...@mpifr-bonn.mpg.de>
> Content-Type: text/plain; charset=utf-8
>
> Hi Jack,
>
> I finally got hold of this issue.
>
> The problem was in the pfb_fir_generic block. After replacing it, the
> fft output was as expected.
>
>
> Cheers,
> Amit
>
> On 06-Nov-15 5:04 PM, Jack Hickish wrote:
> > Hi Amit,
> >
> > I've hastily fixed that error regarding bram latency -- it's pushed to
> > the master casper branch at
> https://github.com/casper-astro/mlib_devel.git
> >
> > You should be able to cherry pick that commit into your repository, but
> > I recommend just using the casper-astro master branch rather than the
> > SMA branch you're currently working with. The SMA code was merged into
> > casper-astro more recently than the commit you are currently at anyway.
> >
> > As for your spectra, I'd suggest seeing if the problem persists with the
> > latest casper-astro master branch and then investigating further from
> there.
> >
> > Cheers,
> > Jack
> >
> >
> > On Fri, 6 Nov 2015 at 11:14 Amit Bansod  > > wrote:
> >
> > Dear All,
> >
> > I am trying to extract 1 channel/band using PFB/FFT (pfb_fir_generic
> &
> > fft_wideband_real blocks from casper library) and I am getting
> > inconsistent result from a 64 channel PFB/FFT.
> >
> > I also found that the for 64 channel FFT, the fft_wideband_real block
> > breaks at
> fft_wideband_real/fft_biplex_real_4x/bi_real_unscr_4x/delay0
> > (or ../bi_real_unscr_4x/delay1) for BRAM latency > 2. Can this be
> also a
> > cause for concern ?
> >
> > I have enclosed the plots of the same band for the 64 & 128 channel
> > FFTs. The BW of 1 band is 12.5 MHz for 128 channels and 25 MHz for 64
> > channels FFT.
> >
> > The design has ASIAA 5g ADCs with fpga running at 200 MHz and same
> noise
> > source is feeding both ADCs.
> >
> > I am using the sma-wideband repository with commit : ecab6f5
> >
> >
> > Regards,
> > Amit Bansod
> >
>
>
>
> --
>
> Message: 2
> Date: Thu, 21 Jan 2016 16:17:04 +0200
> From: Andrew Martens 
> Subject: Re: [casper] Weird FFT Output
> To: Amit Bansod 
> Cc: casper list 
> Message-ID:
> <
> cadewhtdzbzdmesoqbgp39vxjhyov508j0epw-yhxwl3g8s0...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Amit
>
> We have also identified a bug in the pfb_fir_generic block and are working
> on debugging it. Will let you know when we have a solution. Sorry for the
> inconvenience.
>
> Regards
> Andrew
>
> On Thu, Jan 21, 2016 at 11:18 AM, Amit Bansod 
> wrote:
>
> > Hi Jack,
> >
> > I finally got hold of this issue.
> >
> > The problem was in the pfb_fir_generic block. After replacing it, the
> > fft output was as expected.
> >
> >
> > Cheers,
> > Amit
> >
> > On 06-Nov-15 5:04 PM, Jack Hickish wrote:
> > > Hi Amit,
> > >
> > > I've hastily fixed that error regarding bram latency -- it's pushed to
> > > the master casper branch at
> > https://github.com/casper-astro/mlib_devel.git
> > >
> > > You should be able to cherry pick that commit into your repository, but
> > > I recommend just using the casper-astro master branch rather than the
> > > SMA branch you're currently working with. The SMA code was merged into
> > > casper-astro more recently than the commit you are currently at anyway.
> > >
> > > As for your spectra, I'd suggest seeing if the problem persists with
> the
> > > latest casper-astro master branch and then investigating further from
> > there.
> > >
> > > Cheers,
> > > 

[casper] pfb ringing

[Mugundhan vijayaraghavan]

Hello guys,

I was wondering if anyone faced the issue of ringing in the pass-band and
the stop-band when simulation a PFB with a noise signal, when using a PFB
processing a multiple stream.

My initial design was like, I have a quad-adc, the outputs are connected to
a PFB with 2^1 inputs, with bi-plex on, so it would be able to process 4
input streams. The pfb output is FFTd and accumulated. When I checked the
output, i found a kind of ringing in the stop-band and the pass-band of my
output spectra. But when I used individual pfb blocks for each inputs, I
did not have this issue and ringing had disappeared. I have shared the
plots in the following google document.

Has anyone else seen this behaviour with a multi input pfb block ?

Thank you,

Mugundhan

P.S. : google doc link containing the plots:
https://docs.google.com/document/d/1T5wMi2e3Ce_huP0ESohc98QqEuTKnKE_9Ra6qWoqoLU/edit?usp=sharing

[casper] On 10Ge ver 2

[Mugundhan vijayaraghavan]

Hello guys,

Is there any clear documentation on the working of the 10Gbe core's second
version ? Sometimes I see that the design (i.e. tx_valid, tx_eof) work fine
in simulation, but the core does not transmit when testing in real time.
Some times adding a few delay blocks sets the transmission going.

What're the general requirements/precautions while designing a 10G
incorporated design ? Is there some warnings/ optimizations that must be
watched out for before synthesis/implementation ?

In short, how to build a *reliable* 10G design ?

Thanks in advance !

-- 
the giver of moksha

[casper] FFT clocking rates

[Mugundhan vijayaraghavan]

Hello all,

1.) We're trying to build a narrowband spectrometer on Roach I. The idea is
to sample a band of ~ 4 MHz at 48 MHz (as QuADC's minimum sampling is ~ 24
MHz). The band will be centered around 37 MHz. Now, downsampling the
digitized signal at the output of the ADC yellow block by 6 will give us an
equivalent signal of an 8 MHz bw. If I give this input to the FFT, at what
rate will the fft module clock ?  Is there a way to make the FFT
synchronous with the input sample arrival rate ? i.e. 4 MHz ?

2.) Also, Is there any work around to have multiple clock islands using
MSSGE tool-flow ?

Thank you

Mugundhan,

Junior Research Fellow,
Indian Institute of Astrophysics
India

[casper] PFB_FIR queries

[Mugundhan vijayaraghavan]

Hello again,

One other question:
Is there a relation between the taps of the PFB FIR and the number of input
streams to the FFT_Biplex module ?

Size of PFB: (2?)PFBSizeThe number of channels in the PFB (this should also
be the size of the FFT which follows).Total Number of Taps:TotalTapsThe
number of taps in the PFB FIR filter. Each tap uses 2 real multiplier cores
and requires buffering the real and imaginary streams for 2*P**F**B**S**i*
*z**e* samples.Windowing FunctionWindowTypeWhich windowing function to use
(this allows trading passband ripple for steepness of rolloff, etc).Number
of Simultaneous Inputs: (2?)n_inputsThe number of parallel time samples
which are presented to the FFT core each clock. The number of output ports
are set to this same value.

>From the above tab in the blockumentation I see that *number of
simultaneous inputs* is the parallel time samples presented to the fft
core.

Does this mean say, I have a 16384 PFB size, setting the taps as two, this
would give me 2 8192 sample streams, so now, will these 2 8192 sample
streams be the input of the subsequent FFT core ? I.e the number of inputs
must be 1 and the number of input streams must be 2 ?

Kindly clarify !

Mugundhan Vijayaraghavan
Junior Research Fellow
Indian Institute of Astrophysics
-- 
the giver of moksha

Re: [casper] PFB_FIR queries

[Mugundhan vijayaraghavan]

So, does this mean that when I give a PFB size of 16384 and taps of 2, the
module actually takes in 32768 samples, multiplies the window function,
rearranges them as 2 16384 samples, adds them and sends it to the FFT as a
single input stream, where the FFT happens for this number of samples?
Right ?

Also, in the biplex fft block (not 2x or 4x), just the biplex fft, I'm able
to set the "number of inputs" as 1 (ie 2^0) but still the block shows me
two inputs in0 and in1. Can I simply connect a constant 0 block to the
input I don't want to use ? Is there a more elegant way of doing a fft for
a single input stream with only one input ?

Thanks !

On Mon, Dec 14, 2015 at 9:08 PM, Rachel Domagalski <domagal...@berkeley.edu>
wrote:

> The variable PFBsize is the same as your FFT size. The number of taps
> determines the number of filter coefficients in the PFB, which is
> TotalTaps*2^PFBsize. See the wiki page for reference:
> https://casper.berkeley.edu/wiki/The_Polyphase_Filter_Bank_Technique#The_Math_Behind_the_PFB
>
> On Mon, Dec 14, 2015 at 6:16 AM, Mugundhan vijayaraghavan <
> v.vaishnav151...@gmail.com> wrote:
>
>> Hello again,
>>
>> One other question:
>> Is there a relation between the taps of the PFB FIR and the number of
>> input streams to the FFT_Biplex module ?
>>
>> Size of PFB: (2?)PFBSizeThe number of channels in the PFB (this should
>> also be the size of the FFT which follows).Total Number of Taps:TotalTapsThe
>> number of taps in the PFB FIR filter. Each tap uses 2 real multiplier cores
>> and requires buffering the real and imaginary streams for 2*P**F**B**S*
>> *i**z**e* samples.Windowing FunctionWindowTypeWhich windowing function
>> to use (this allows trading passband ripple for steepness of rolloff, 
>> etc).Number
>> of Simultaneous Inputs: (2?)n_inputsThe number of parallel time samples
>> which are presented to the FFT core each clock. The number of output ports
>> are set to this same value.
>>
>> From the above tab in the blockumentation I see that *number of
>> simultaneous inputs* is the parallel time samples presented to the fft
>> core.
>>
>> Does this mean say, I have a 16384 PFB size, setting the taps as two,
>> this would give me 2 8192 sample streams, so now, will these 2 8192 sample
>> streams be the input of the subsequent FFT core ? I.e the number of inputs
>> must be 1 and the number of input streams must be 2 ?
>>
>> Kindly clarify !
>>
>> Mugundhan Vijayaraghavan
>> Junior Research Fellow
>> Indian Institute of Astrophysics
>> --
>> the giver of moksha
>>
>
>


-- 
the giver of moksha

[casper] Error when calling bee_xps in matlab

[Mugundhan vijayaraghavan]

Hi,
I'm using Matlab R2014a along with Xilinx ISE 13.2 in windows 7 x64
version. My SysGen version is also the same. I downloaded the Casper
libraries from the Git repository.
I have linked the Casper libraries to Simulink and the Xilinx SysGen
libraries are also linked (I'm able to see Xilinx blocksets and Casper,
BEE2 and Gvart blocksets in Simulink library browser).
My Casper toolboxes are in the location: E:\Casper_Libraries\mlib_devel,
So i set the
MLIB_ROOT value as E:\Casper_Libraries\mlib_devel and my xps_lib is also in
the same location, so my BEE2_XPS_LIB also has the same value as MLIB_ROOT.
after this, when I try to compile the tutorial with bee_xps, i get the
following error :

Detected Windows OS
Error using gen_xps_files (line 99)
Error in specification of object or property name and value pairs

How to rectify this?
Please guide
-- 
Mugundhan Vijayaraghavan
Gauribidanur Radio Observatory
IIA

[casper] Thesis Request

[Mugundhan vijayaraghavan]

Hi all,

Link in the thesis section for A.Parsons'  thesis . Low-Frequency
Interferometry: Design, Calibration, and Analysis Towards Detecting the
Epoch of Reionization.
http://setiathome.berkeley.edu/%7Eaparsons/misc/thesis.pdf is not working.

Where can I get a copy of the same ?

Thanks!

Mugundhan Vijayaraghavan,
Int. M.Tech Phd,
Gauribidanur Radio Observatory
Indian Institute of Astrophysics

Re: [casper] Thesis Request

[Mugundhan vijayaraghavan]

Thank you Dr. Aaron :D


On Tue, Jun 24, 2014 at 10:14 PM, Aaron Parsons 
apars...@astron.berkeley.edu wrote:

 I've reposted to http://astro.berkeley.edu/~aparsons/thesis.pdf


 On Tue, Jun 24, 2014 at 4:26 AM, Mugundhan vijayaraghavan 
 v.vaishnav151...@gmail.com wrote:

 Hi all,

 Link in the thesis section for A.Parsons'  thesis . Low-Frequency
 Interferometry: Design, Calibration, and Analysis Towards Detecting the
 Epoch of Reionization.
 http://setiathome.berkeley.edu/%7Eaparsons/misc/thesis.pdf is not
 working.

 Where can I get a copy of the same ?

 Thanks!

 Mugundhan Vijayaraghavan,
 Int. M.Tech Phd,
 Gauribidanur Radio Observatory
 Indian Institute of Astrophysics




 --
 Aaron Parsons
 510-306-4322
 Hearst Field Annex B54, UCB




-- 
the giver of moksha