[Discuss-gnuradio] Error in creating block
Hi.. I crated a block named 'costas_loop_cc'. but when I connect to test this block with NULL sink and NULL Source, shows the error like this: Error 1: Generating: "/home/lekha/top_block.py" Executing: "/home/lekha/top_block.py" File "/home/lekha/top_block.py", line 31 self.costas_loop_cc_0 = > ^ SyntaxError: invalid syntax >>> Done the part of the generated top_block.py code related to error is: ## # Blocks ## self.costas_loop_cc_0 = >line 31 cannot find 'loop_bw': digital.costas_loop_cc($loop_bw, $order) < self.blocks_null_source_0 = blocks.null_source(gr.sizeof_gr_complex*1) self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1) ## # Connections ## self.connect((self.blocks_null_source_0, 0), (self.costas_loop_cc_0, 0)) self.connect((self.costas_loop_cc_0, 0), (self.blocks_null_sink_0, 0)) I wish it is a small error but I couldn’t get. while creating a block when I execute gr_modtool makexml command it shows the error : AttributeError: 'NoneType' object has no attribute 'group'. what does it mean AttributeError? Is there any relation with this to above mentioned error. thanks for your advice ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in creating block
Hi Vishwanatha, the generated python is bogus; the "-->line31...<--" should not be there. This indicates that there is something wrong with your GRC XML file, most probably the python command in the tag is failing. Reading the line "cannot find 'loop_bw': digital.costas_loop_cc($loop_bw, $order)", I'd assume that you meant to use loop_bw as a parameter to your block's constructor/make function, but maybe forgot to define it somewhere else (or you've got a typo). Greetings, Marcus On 04/02/2015 11:03 AM, Vishwanatha H G wrote: > Hi.. > I crated a block named 'costas_loop_cc'. but when I connect to test > this block with NULL sink and NULL Source, shows the error like this: > Error 1: > Generating: "/home/lekha/top_block.py" > Executing: "/home/lekha/top_block.py" > > File "/home/lekha/top_block.py", line 31 > self.costas_loop_cc_0 = > > ^ > SyntaxError: invalid syntax > > >>> Done > > the part of the generated top_block.py code related to error is: >## > # Blocks > ## > self.costas_loop_cc_0 = >line 31 > cannot find 'loop_bw': digital.costas_loop_cc($loop_bw, $order) > < > self.blocks_null_source_0 = > blocks.null_source(gr.sizeof_gr_complex*1) > self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_gr_complex*1) > > ## > # Connections > ## > self.connect((self.blocks_null_source_0, 0), > (self.costas_loop_cc_0, 0)) > self.connect((self.costas_loop_cc_0, 0), > (self.blocks_null_sink_0, 0)) > > I wish it is a small error but I couldn’t get. while creating a block > when I execute gr_modtool makexml command it shows the error : > > AttributeError: 'NoneType' object has no attribute 'group'. > > what does it mean AttributeError? Is there any relation with this to > above mentioned error. thanks for your advice > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS
Dear Sir, Thanks, this solve the problems. The GNU Radio has been installed successfully using PyBOMBS. Thank you very much. On Thu, Apr 2, 2015 at 10:30 AM, Ron Economos wrote: > The actual fix is a little more complicated. You can download a patched > file from here: > > http://www.w6rz.net/dvbt2_paprtr_cc_impl.cc > > w6rz.net is my personal website. > > Ron > > > On 04/01/2015 07:11 PM, Activecat wrote: > > Dear Sir, > > I have comment out the "#include ", but still has error, as > below: > > [ 80%] Building CXX object > gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o > [ 86%] Built target gnuradio-qtgui > [ 86%] Built target fcd_nfm_rx > [ 87%] Built target test_atsci > [ 87%] Built target _atsc_swig > [ 87%] Built target _qtgui_swig > [ 88%] Built target gnuradio-channels > [ 88%] Built target _channels_swig > [ 92%] Built target gnuradio-digital > [ 92%] Built target _digital_swig > [ 98%] Built target gnuradio-trellis > [ 98%] Built target _trellis_swig > > /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc: > In member function ‘virtual int gr::dtv::dvbt2_paprtr_cc_impl::work(int, > gr_vector_const_void_star&, gr_vector_void_star&)’: > > /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:770:102: > error: ‘_Complex_I’ was not declared in this scope > > /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:771:37: > error: ‘cexp’ was not declared in this scope > > /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:772:48: > error: ‘creal’ was not declared in this scope > > /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:773:49: > error: ‘cimag’ was not declared in this scope > make[2]: *** > [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o] > Error 1 > make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2 > make: *** [all] Error 2 > Build failed. See output above for error messages. > > > The complete log is at > https://github.com/activecat/gnuradio/blob/master/installation_log_003.txt > Please advise, thanks. > > > On Thu, Apr 2, 2015 at 9:49 AM, Ron Economos wrote: > >> In your previous pull request, you deleted the line: >> >> #include >> >> in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc >> >> This would directly fix the build issues reported by Activecat and Marcus >> Leech. >> >> Ron >> >> On 04/01/2015 06:34 PM, Michael Dickens wrote: >> >>> I'm not sure my forthcoming pull request directly addresses these >>> specific issues, but it does a bunch of others for C++11 compliance in >>> std::complex -- whether or not you're using C++11; it's backward compatible >>> with C++0x and earlier, and should be forward compatible as well. Before we >>> address these specific issues, let's get my patches in place -- they remove >>> all of the GCC extensions to std::complex, so they might have an impact on >>> these issues. I should be able to do the PR tomorrow; still testing on >>> various systems tonight. - MLD >>> On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote: >>> I believe Michael Dickens will have a comprehensive fix for issues like this soon. >>> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks
W dniu 01.04.2015 o 12:10, Marcus Müller pisze:
> Hi Piotr,
>
> nice to hear you got a step ahead!
> so,
>> I did that and what I obtained was:
>> ---
>> 16 Thread 0x7fffbdffb700 (LWP 13462) "python"
>> pthread_cond_wait@@GLIBC_2.3.2 () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>> 3Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>> * 1Thread 0x77fc7740 (LWP 13444) "python" 0x778e8da3 in
>> select () at ../sysdeps/unix/syscall-template.S:81
>> ---
>
> I'd have a blind guess:
> Thread 16 might be the "surviving" part of a python-spawned Timer()
> thread, which caused a message _post at another thread, which might be
> something that hangs if that block's thread no longer exists.
>
> Can you switch to that thread:
> thread 16
> and then try to get a python backtrace [1]
> py-bt
> and maybe a simple C-style backtrace
> bt
>
> that might give you some information what is actually waiting on a
> condition (which is what I guess from "pthread_cond_wait").
>
> Greetings,
> Marcus
>
> [1] for this to work, you might need to follow these instructions from
> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:
>
> ... make sure that the python development package is installed
> (|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for
> some systems, you should append the content of
> |/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
> |~/.gdbinit|, and re-start |gdb|.
>
Marcus,
Regarding the timer - this is what I thought at first, so I removed it
from the block. It didn't help, so I removed almost everything leaving
only message input of the block. But the problem persisted.
I will try you advice with GDB and let everybody know of the result.
Best Regards,
Piotr
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OOK modulation naming
A friend recently showed me an OOK modulation that I had never seen before, and I'm wondering if anyone knows a name for this scheme. It is PWM where both the on periods and off periods carry data in their durations. In the example we observed, an on or off period with a duration of two units represents a zero. An on or off period with a duration of one unit represents a one. Example: --_-_--_--__- This sequence of amplitudes represents the binary data 011101001. Note that this scheme has a variable data rate. (Two packets carrying the same number of bits may have different durations.) Overall, however, the data rate is higher than in a similar looking scheme in which data are encoded only in the on periods. Does anyone know what to call this? I am tempted to call it Biphase PWM. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOK modulation naming
Why not make the ratio 1:3 and then you could call it Morse PWM. :-) On 4/2/2015 2:16 PM, Michael Ossmann wrote: A friend recently showed me an OOK modulation that I had never seen before, and I'm wondering if anyone knows a name for this scheme. It is PWM where both the on periods and off periods carry data in their durations. In the example we observed, an on or off period with a duration of two units represents a zero. An on or off period with a duration of one unit represents a one. Example: --_-_--_--__- This sequence of amplitudes represents the binary data 011101001. Note that this scheme has a variable data rate. (Two packets carrying the same number of bits may have different durations.) Overall, however, the data rate is higher than in a similar looking scheme in which data are encoded only in the on periods. Does anyone know what to call this? I am tempted to call it Biphase PWM. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOK modulation naming
Hey Mike, I think that NRZI. - Jeff On 04/02/2015 02:36 PM, John Ackermann N8UR wrote: Why not make the ratio 1:3 and then you could call it Morse PWM. :-) On 4/2/2015 2:16 PM, Michael Ossmann wrote: A friend recently showed me an OOK modulation that I had never seen before, and I'm wondering if anyone knows a name for this scheme. It is PWM where both the on periods and off periods carry data in their durations. In the example we observed, an on or off period with a duration of two units represents a zero. An on or off period with a duration of one unit represents a one. Example: --_-_--_--__- This sequence of amplitudes represents the binary data 011101001. Note that this scheme has a variable data rate. (Two packets carrying the same number of bits may have different durations.) Overall, however, the data rate is higher than in a similar looking scheme in which data are encoded only in the on periods. Does anyone know what to call this? I am tempted to call it Biphase PWM. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOK modulation naming
I though NRZI had a constant symbol rate. I would expect 011101001 in NRZI to look like: _-_--___- Mike On Thu, Apr 02, 2015 at 03:23:57PM -0400, Jeff Long wrote: > > Hey Mike, > > I think that NRZI. > > - Jeff > > On 04/02/2015 02:36 PM, John Ackermann N8UR wrote: > > Why not make the ratio 1:3 and then you could call it Morse PWM. :-) > > > > On 4/2/2015 2:16 PM, Michael Ossmann wrote: > >> A friend recently showed me an OOK modulation that I had never seen > >> before, and I'm wondering if anyone knows a name for this scheme. > >> > >> It is PWM where both the on periods and off periods carry data in their > >> durations. > >> > >> In the example we observed, an on or off period with a duration of two > >> units represents a zero. An on or off period with a duration of one > >> unit represents a one. Example: > >> > >> --_-_--_--__- > >> > >> This sequence of amplitudes represents the binary data 011101001. > >> > >> Note that this scheme has a variable data rate. (Two packets carrying > >> the same number of bits may have different durations.) Overall, > >> however, the data rate is higher than in a similar looking scheme in > >> which data are encoded only in the on periods. > >> > >> Does anyone know what to call this? I am tempted to call it Biphase > >> PWM. > >> > >> Thanks, > >> > >> Mike > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OOK modulation naming
After way to much searching ... under Anisochronous modulation, there is something called Digital Pulse Interval Width Modulation (DPIWM). http://paradise.caltech.edu/papers/thesis010.pdf Seems like as good a name as any. - Jeff On 04/02/2015 03:28 PM, Michael Ossmann wrote: I though NRZI had a constant symbol rate. I would expect 011101001 in NRZI to look like: _-_--___- Mike On Thu, Apr 02, 2015 at 03:23:57PM -0400, Jeff Long wrote: Hey Mike, I think that NRZI. - Jeff On 04/02/2015 02:36 PM, John Ackermann N8UR wrote: Why not make the ratio 1:3 and then you could call it Morse PWM. :-) On 4/2/2015 2:16 PM, Michael Ossmann wrote: A friend recently showed me an OOK modulation that I had never seen before, and I'm wondering if anyone knows a name for this scheme. It is PWM where both the on periods and off periods carry data in their durations. In the example we observed, an on or off period with a duration of two units represents a zero. An on or off period with a duration of one unit represents a one. Example: --_-_--_--__- This sequence of amplitudes represents the binary data 011101001. Note that this scheme has a variable data rate. (Two packets carrying the same number of bits may have different durations.) Overall, however, the data rate is higher than in a similar looking scheme in which data are encoded only in the on periods. Does anyone know what to call this? I am tempted to call it Biphase PWM. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Demodulating short bursts of BPSK
I have an application that needs to decode short bursts of DBPSK data (which I am not generating myself). The problem I am having is that the standard PSK Demod blocks don't lock up in time to correctly decode the first few flags in the packetised data, which means I generally lose the first packet. Is there a solution to this - e.g. once the demodulator has locked up, go back some time (samples) and start again knowing the locked parameters? Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating short bursts of BPSK
Mike, Let's call short bursts of data packets (because that’s really what they are). In packet transmissions, there are a few ways of ensuring that the synchronizers have enough time to lock up. The easiest way for you to go about this, is adding a packet header that carries no information, such as 101010101, but can be used by the sync blocks to synchronize. The sync blocks require transitions to make the magic happen. If you add this in front of all your real data bursts, you will lose some of those SYNC frame bits each time, but you don't care about that because it's not real data AND the synchronizers will be locked by the time the real data starts. v/r, Rich On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis wrote: > I have an application that needs to decode short bursts of DBPSK data > (which I am not generating myself). The problem I am having is that > the standard PSK Demod blocks don't lock up in time to correctly > decode the first few flags in the packetised data, which means I > generally lose the first packet. Is there a solution to this - e.g. > once the demodulator has locked up, go back some time (samples) and > start again knowing the locked parameters? > > Mike > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Demodulating short bursts of BPSK
If the packets have a preamble, there's a block called correlate_and_sync which should do what you want, although it has some issues. See a thread I started a few days ago about that... On Thu, Apr 2, 2015 at 3:36 PM, Mike Willis wrote: > I have an application that needs to decode short bursts of DBPSK data > (which I am not generating myself). The problem I am having is that > the standard PSK Demod blocks don't lock up in time to correctly > decode the first few flags in the packetised data, which means I > generally lose the first packet. Is there a solution to this - e.g. > once the demodulator has locked up, go back some time (samples) and > start again knowing the locked parameters? > > Mike > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on Zedboard
Philip Balister wrote: > On 04/01/2015 04:53 PM, Alireza Khodamoradi wrote: > > Thank you Philip! > > > > I also don't have the audio jack working. Should I ask it on the > > meta-xilinx list? > > Bug them. It is also likely a driver issue. My understanding is there are a > bunch of > analog devices parts on the board that they wrote drivers for. There is a different kernel that we (Analog Device's) maintains, which includes both ALSA drivers for the audio chip (ADAU1761) and the HDMI output (ADV7511). https://github.com/analogdevicesinc/linux there are a few zynq branches in there. Normally Xilinx pulls drivers from there for their kernels, but anyone can do the same. Our build instructions (if that's the sort of thing you want to do) is at: http://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/software/linux/zynq_2014r2 We provide binaries for Zed which includes a 3.17 kernel and Xbuntu/xfce for many of the FMC prototyping cards we make. http://wiki.analog.com/resources/tools-software/linux-software/zynq_images This does include GNURadio (3.7.4) binary, which some people used/contributed. This doesn't support the GNURadio FPGA accelerator work that was done. (if that is what you were really looking for). > I'm not sure if > those drivers made it into upstream Linux, and then you have the issue of the > best kernel for our purposes is about 3.14. Upstream - it's hard to upstream the device side, when Xilinx hasn't upstream the DMA side. Greg (and others) do not like half a driver. Things are getting better now, and we need to focus on that more. -Robin > > > > On Wed, Apr 1, 2015 at 4:50 PM, Philip Balister wrote: > > > >> On 03/31/2015 11:39 AM, Alireza Khodamoradi wrote: > >>> Philip, > >>> > >>> I got it working. For some reason if I use *Ubuntu's Archive > >>> Manager* on > >> my > >>> laptop to uncompress the .xz file, it doesn't work! > >>> > >>> I had to uncompress it by this command: *unxz -d > >>> sdimage-8G-zedboard.direct.xz* in order to get it work. > >>> > >>> Now I have a linux running on the zedboard with the gnu-radio. But I > >> can't > >>> get the VGA to work - I have to use UART to connect to the linux - I > >>> saw > >> it > >>> has *startx* , is there any way for me to get the VGA working? > >> > >> I'd ask on the meta-xilinx list. We use hte BSP from Xilinx, which I > >> do not think has support for the video display. For that you need a > >> special driver (and I believe you need some stuff in the fpga). The > >> build we have doesn't depend on anything loaded in the fpga. > >> > >> Philip > >> > >>> > >>> Thank you, > >>> Alireza > >>> > >>> On Fri, Mar 20, 2015 at 6:54 AM, Philip Balister > >>> > >>> wrote: > >>> > On 03/19/2015 10:48 AM, Alireza Khodamoradi wrote: > > Here are the files I have in the FAT partition (boot): > > > > 1- boot.bin > > 2- u-boot.img > > 3- uEnv.txt > > 4- uImage > > 5- zc702-zynq7.dtb > > > > * I used this image: *sdimage-8G-zc702.direct* > > So this all looks correct. When you put the card in the PC both the > FAT and roofs partitions are mounted OK? You did use an 8G card? > > I'm not sure what to say at this point. Everything looks OK. I am > traveling and away from borads for a few weeks. > > Philip > > > > > On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister > > > > wrote: > > > >> On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote: > >>> Philip, > >>> > >>> Thank you for letting me using your images. I tried both of them > >>> with > >> the *dd > >>> *command, it took me around 2000 seconds (30 mins) each and > >>> after > >> using > >>> them on the board I get the following message via the UART: > >>> > >>> *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)* *mmc boot* > >>> *reading fpga.bin* > >>> *spl: error reding image fpga.bin, err - -1* *reading > >>> system.dtb* > >>> *spl: error reading image system.dtb, err - -1* *reading > >>> u-boot.img* > >>> *spl: error reading image u-boot.img, err - -1* *### ERROR ### > >>> Please RESET the board ###* > >> > >> So the first stage boot loader is running, which is good. > >> > >> It looks for a couple of files which should be there, which is OK. > >> (fpga.bin and system.dtb) > >> > >> Then it tries to load u-boot.img which it doesn't find. This is bad. > >> > >> Can you put the card in a PC and send the list of file in the FAT > >> partition? > >> > >> Philip > >> > >> > >>> > >>> I got the above message for sdimage-8G-zc702.direct. I get no > >>> message > for > >>> the other image. > >>> > >>> What am I doing wrong? > >>> > >>> On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister < > >> phi...@balister.org > > > >>> wrote: > >>> > On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote: > >
