[beagleboard] Re: Serial Communication on Beaglebone Black

['ts' via BeagleBoard]

You need to activate the serial port first.
http://beaglebone.cameon.net/home/serial-ports-uart

Am Mittwoch, 18. Mai 2016 22:46:20 UTC+2 schrieb Shaurabh Kumar Singh:
>
> I have been trying to communicate with a CNC machine through RS 232 to the 
> Beaglebone Black. 
> Following are the Serial Port settings at the Machine
> Baudrate=9600
> Databits=8
> Stopbits=1
> Parity=None
> CR only
>
> When i tried connecting it to my desktop(windows 10-using python) 
> directly(done without using BBB) and i set the same parameters i got the 
> response from the machine like i had expected.
>
> Although, when done using the BBB (debian), also using python, i just 
> received the string command i sent to the machine. Following is the python 
> code.
>
> import Adafruit_BBIO.UART as UART
>
> import serial, string
>
> UART.setup("UART1")
> with serial.Serial(port="/dev/ttyO0",baudrate=9600,timeout=2) as ser: #i 
> also tried mentioning databits and stopbits and other parameters but they 
> still did not work
> ser.write(b"Q100\r")
> c=ser.readline().decode("utf-8","ignore")
> print(c)
> ser.close()
>
> This works all fine in windows(gives the serial no. as the output) but 
> simply gives back Q100as output (same as input).
>
> I was wondering if it could be due to the different OS on my laptop and 
> BBB. Should i try installing windows ce on the BBB and work with that?
>
>
> Thank you
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0b12d828-dd4b-46d0-89c5-9ed6ddd95431%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] TPS65217 & Vdd_core 1.125V or 1.2V or 1.1V or .... ?

[Micka]

I already looked at that file and in the starterware there is no line that
contain DEFDCD3.

What I'm saying, is that nowhere I find the same value for DEFDCD3. Some
time it's 1.125V, somehwere else it's .95V-1.1V and in the BB_SRM it is
1.1V .

I'm asking to Gerald, what is the correct value for Vdd_Core ? I think that
the correct one is 1.1V. And what is the range ? 0.95V-1.1V ( device tree )

Le mer. 18 mai 2016 à 22:31, John Syne  a écrit :

> On May 18, 2016, at 1:58 AM, Micka  wrote:
>
> Hi,
>
> In the u-boot
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;h=4330be64994dc6cbfaff4b865fee44d82f660a3d;hb=HEAD#l255
>
> there is those lines :
>
> 255
> 
> /* Set DCDC3 (CORE) voltage to 1.125V */
> 256
> 
> if (tps65217_voltage_update(TPS65217_DEFDCDC3,
> 257
> 
> TPS65217_DCDC_VOLT_SEL_1125MV))
>
>
> In the device tree there is those lines :
>
> dcdc3_reg: regulator@2 {
> /* VDD_CORE voltage limits *0.95V -* *1.1V* with +/-4% tolerance */
> regulator-name = "vdd_core";
> regulator-min-microvolt = <925000>;
> regulator-max-microvolt = <115>;
> regulator-boot-on;
> regulator-always-on;
> };
>
> in the starterware from texas + the patch for the bbb I have nothing
> concerning the DEFDCD3.
>
> And finally in the BBB_SRM you have those lines :
>
> The VDD_CORE rail can deliver up to 1.2A at 1.1V. This rail is not
> accessible for use anywhere else on the board and only connects to the
> processor. This rail is fixed at 1.1V and is not scaled.
>
> So what is the correct configuration for this output ?
>
> I believe this is done in bootloader/src/armv7a/am335x/bl_platform.c
>
> In essence, you have to create a bootable SDCard for Starterware which
> sets the regulator voltages for you.
>
> Regards,
> John
>
>
>
> Micka,
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtm7heTJ45tuWoHt9v1ajBV4XN%2BCk7t%2BfGTn-mrjjJsD%2BA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/D2B2F1F3-E3ED-43C6-9B24-2D32028E99B4%40gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DekMzxdLE6J%2BnUF6aef7EC78EUg_GPRzA76_yAPk%3DiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

Have a look at https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
Depending on current/temperature  they have much better life,  up to 10,000
cycles
and much better fire safety than LiPo,  you may even be able to ship then
on flights.

Supper caps,  don't have a good life time,  in fact they much worse
then Aluminum
Capacitors

example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
more life at 25C
and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
$2  in 5k
where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs
@ 70°C and cost $6.000 in 5k
(Digikey prices)
So to get the Max life,  use the step up switching reg to say 40V
(remember that energy on capt is = 1/2CV^2 )
so double the voltage is 4 times the energy)  then user a switch to step
down to you required voltage/current
So for max and life,  only switch to the backup Caps when power fail's,
that way they remain cool,
give max life,  and will give you  good hold times.  And of course all
under mic-controller control.
per my example circuit.. (example dose not have the control circuit, but
can be easily added )

Lachlan




On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:

>
> > You can sum it all up into this; The problem is completely solved by
> using a battery and having acpid installed. Except you need a way to
> completely disconnect power, from the BBB's input, for a single, or perhaps
> two corner cases that would otherwise require a hard reset.
>
> I love the no-nonsense mentality, and quality design behind this approach
> for most use cases.  But, for some high-reliability use cases like mine --
> a device permanently installed in a remote, client wall — batteries aren’t
> a great fit.
>
> For long-term accessibility:Battery maintenance, even after
> years of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of
> installing LiPo, which is known to have potential fire issues, into a
> client’s wall.
> For shipping reasons:   The added hassle of international
> shipping of LiPo-based systems.
>
> > All these fancy high cost solutions are honestly ridiculous, and if you
> can just use an OTS UPS . . .
>
>  Hardware cost is relative.  The “high” cost (<$100) of a system
> design is nothing, if it will potentially save me things like panicked
> client calls, last-minute international plane tickets and high-pressure
> field repairs.  Those just aren’t fun.  Obviously every project out there
> isn’t heading to a NASA rover, but in some lines of work this kind of
> service is expected when a high-end, mission-critical system goes down.  In
> the end, if I do my job right, the price is just passed on to the client
> who is willing to pay a premium for a high reliability, maintenance-free
> product.
>
> I’d like to be able to deploy those systems based on the BBB, because I
> know it, find the platform highly versatile, and a good match for the
> variety of projects I take on.  I think the PRUs especially make this a
> very unique little SoC.
>
> Best,
> ST
>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MtdXLKP3VUTav_d_uGew4OAQfWT0iVSO9Zd6%2B5a0pYxUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[bambaloe1969]

Just curious.
What is the current state of affairs?

My order at mouser dot com gives me a dispatch Date first of august.

Patrick


Op donderdag 7 april 2016 03:12:46 UTC+2 schreef Gerald:
>
> Yes indeed.
>
> Gerald
>
>
> On Wed, Apr 6, 2016 at 7:51 PM, Dennis Lee Bieber  > wrote:
>
>> On Wed, 6 Apr 2016 08:54:24 -0500, Gerald Coley
>> > declaimed the following:
>>
>> >1. We expect PCBs here in another week. 4/13/2016
>> >2. 1 week for assembly.4/20/2015
>> >3. 1 week for test and bring up. 4/27/2016
>> >4. 1 week for FCC testing 5/4/2016
>> >5. First 500 boards shipping 2 weeks later. 5/18/2016
>> ... contingent on passing FCC, I'm sure
>> --
>> Wulfraed Dennis Lee Bieber AF6VN
>> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
> gco...@emprodesign.com 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5b5596ae-6d41-4b07-a231-bf52cc0ab39e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Getting Bootchart setup on Debian 8.3

[John Baker]

Thanks Micka.

I just now tried that and putty.exe said that ntp isn't installed, so 
not removed, but I'll bet it's gotta be something like that. Maybe 
something for the Internet connection.


John


On 5/18/2016 8:33 PM, Micka wrote:

sudo apt-get remove ntp

Le mer. 18 mai 2016 23:53, John Baker > a écrit :


Robert:
What script is trying to read the clock data from ntp? I have an
Adafruit DS3231 for the Real Time Clock and the BBB is taking a
minute before it gets the clock from the DS3231 so I suspect some
script is trying to read the ntp clock data and holding up the
read of my DS3231 clock. Es posible?
John

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to beagleboard+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/beagleboard/66884716-e25b-412e-98f1-97870f8f7127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the 
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/beagleboard/Rtn0sS_z9DA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
beagleboard+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DQWMYfn_4Ox9gGox9HYjtPC8Z7HTNbKESAevfEseYEA%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/af3c4179-e373-0cc9-4665-b8bbf5b91bfb%40ieee.org.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[Gerald Coley]

http://elinux.org/Beagleboard:BeagleBoard-X15#BeagleBoard-X15_Description

Gerald

On Thu, May 19, 2016 at 3:44 AM,  wrote:

> Just curious.
> What is the current state of affairs?
>
> My order at mouser dot com gives me a dispatch Date first of august.
>
> Patrick
>
>
> Op donderdag 7 april 2016 03:12:46 UTC+2 schreef Gerald:
>>
>> Yes indeed.
>>
>> Gerald
>>
>>
>> On Wed, Apr 6, 2016 at 7:51 PM, Dennis Lee Bieber 
>> wrote:
>>
>>> On Wed, 6 Apr 2016 08:54:24 -0500, Gerald Coley
>>>  declaimed the following:
>>>
>>> >1. We expect PCBs here in another week. 4/13/2016
>>> >2. 1 week for assembly.4/20/2015
>>> >3. 1 week for test and bring up. 4/27/2016
>>> >4. 1 week for FCC testing 5/4/2016
>>> >5. First 500 boards shipping 2 weeks later. 5/18/2016
>>> ... contingent on passing FCC, I'm sure
>>> --
>>> Wulfraed Dennis Lee Bieber AF6VN
>>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>> gco...@emprodesign.com
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5b5596ae-6d41-4b07-a231-bf52cc0ab39e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BcUX%3DPt33amiqC-FtL9iU1ii2w%2BnZTej8kcXiHBOX2kow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Getting Bootchart setup on Debian 8.3

[Micka]

As Robert told u, you need to disable the service
systemd-timesyncd:

systemctl disable systemd-timesyncd

Le jeu. 19 mai 2016 13:27, John Baker  a écrit :

> Thanks Micka.
>
> I just now tried that and putty.exe said that ntp isn't installed, so not
> removed, but I'll bet it's gotta be something like that. Maybe something
> for the Internet connection.
>
> John
>
> On 5/18/2016 8:33 PM, Micka wrote:
>
> sudo apt-get remove ntp
>
> Le mer. 18 mai 2016 23:53, John Baker < 
> bakerengineerin...@gmail.com> a écrit :
>
>> Robert:
>> What script is trying to read the clock data from ntp? I have an Adafruit
>> DS3231 for the Real Time Clock and the BBB is taking a minute before it
>> gets the clock from the DS3231 so I suspect some script is trying to read
>> the ntp clock data and holding up the read of my DS3231 clock. Es posible?
>> John
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 
>> https://groups.google.com/d/msgid/beagleboard/66884716-e25b-412e-98f1-97870f8f7127%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
>
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Rtn0sS_z9DA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DQWMYfn_4Ox9gGox9HYjtPC8Z7HTNbKESAevfEseYEA%40mail.gmail.com
> .
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/af3c4179-e373-0cc9-4665-b8bbf5b91bfb%40ieee.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtkBcrRJ3Z%2B7m8QRf-xMHzsBRdHZ_Xj8arENzfLaVkRRvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eQEP Quadrature detector

[Wim Hellenthal]

 

Please help,

 

I've already posted a mail before but got no reaction. I'm desperately 
looking for support. I have a running quadrature detector using pin P8_12 
and P8_11 (eqep2), see the attached dts file. The code I’m using is based 
on accessing the eQEP register using memory mapped IO (mmio). 

 

I’ve have used the detector without any problems on a BBB board running the 
following debian version:

Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l 
GNU/Linux

 

Now I’m trying to run exactly the same code on a newer debian version. This 
is not working anymore!  I managed to download and install the 
following debian version (among some other versions):

Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 
UTC 2014 armv7l GNU/Linux

 

Note that I installed the bone50 version on a different BBB board. I don’t 
want to mess up the correct working bone47 board. Both board have 4G eMMC 
memory (revision - C) 

What I notice is that the folder structure for both version is different: 



For Bone47 it is:  /sys/devices/ocp.3/48304000.epwmss 

For Bone50 it is:  
/sys/devices/ocp.3/48304000.epwmss/48304180.eqep


Bone47; No means to read the position and the like. 

Bone50; Reading the position using *cat position* alway return zero, this 
is also what I see running the mmio code. 


So what could be the cause that the quadrature detector is no longer 
working on debian version higher than 3.8.13-bone47? At least the folder 
structure is different. Is this a kernel driver issue? Do I have to 
redefine the .dts file? Any help would be highly appreciated. 

 

Best regards,

Wim

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5bcb57fb-0cc5-42a2-b861-2ed059a5970f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


bone_eqep2-00A0.dts
Description: Binary data

Re: [beagleboard] Re: MT7601u 148f:7601 driver for Ubuntu 16.04 Xenial & HostAPD

[Robert Nelson]

Which kernel?

uname -r
On May 18, 2016 11:53 PM, "Jason Mumby"  wrote:

> Not sure what is then ..
>
> ubuntu@arm:~/bin$ sudo ifconfig -a
> eth0  Link encap:Ethernet  HWaddr 90:59:af:82:2e:09
>   inet addr:192.168.2.19  Bcast:192.168.2.255  Mask:255.255.255.0
>   inet6 addr: fe80::9259:afff:fe82:2e09/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:11526 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:3236 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:2134852 (2.1 MB)  TX bytes:434086 (434.0 KB)
>   Interrupt:175
>
>
> loLink encap:Local Loopback
>   inet addr:127.0.0.1  Mask:255.0.0.0
>   inet6 addr: ::1/128 Scope:Host
>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>   RX packets:170 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:170 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:12610 (12.6 KB)  TX bytes:12610 (12.6 KB)
>
>
> usb0  Link encap:Ethernet  HWaddr 90:59:af:82:2e:00
>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
>
>
> On Thursday, May 19, 2016 at 4:29:44 PM UTC+12, RobertCNelson wrote:
>>
>> usb0 is not your interface to mt7601u...
>>
>> sudo ifconfig -a
>> On May 18, 2016 10:37 PM, "Jason Mumby"  wrote:
>>
>>> ubuntu@arm:~$ hostapd -dd /etc/hostapd/hostapd.conf
>>> random: Trying to read entropy from /dev/random
>>> Configuration file: /etc/hostapd/hostapd.conf
>>> Could not read interface usb01 flags: No such device
>>> nl80211: Driver does not support authentication/association or connect
>>> commands
>>> nl80211: deinit ifname=usb01 disabled_11b_rates=0
>>> nl80211: Remove monitor interface: refcount=0
>>> netlink: Operstate: ifindex=0 linkmode=0 (kernel-control), operstate=6
>>> (IF_OPER_UP)
>>> Could not read interface usb01 flags: No such device
>>> nl80211: Set mode ifindex 0 iftype 2 (STATION)
>>> nl80211: Failed to set interface 0 to mode 2: -1 (Operation not
>>> permitted)
>>> nl80211: Try mode change after setting interface down
>>> Could not read interface usb01 flags: No such device
>>> Could not read interface usb01 flags: No such device
>>> nl80211: Failed to set interface up after switching mode
>>> nl80211: Interface mode change to 2 from 0 failed
>>> nl80211 driver initialization failed.
>>> hostapd_interface_deinit_free(0x7f98e410)
>>> hostapd_interface_deinit_free: num_bss=1 conf->num_bss=1
>>> hostapd_interface_deinit(0x7f98e410)
>>> usb01: interface state UNINITIALIZED->DISABLED
>>> hostapd_bss_deinit: deinit bss usb01
>>> usb01: AP-DISABLED
>>> hostapd_cleanup(hapd=0x7f98eee8 (usb01))
>>> hostapd_free_hapd_data: Interface usb01 wasn't started
>>> hostapd_interface_deinit_free: driver=(nil) drv_priv=(nil) -> hapd_deinit
>>> hostapd_interface_free(0x7f98e410)
>>> hostapd_interface_free: free hapd 0x7f98eee8
>>> hostapd_cleanup_iface(0x7f98e410)
>>> hostapd_cleanup_iface_partial(0x7f98e410)
>>> hostapd_cleanup_iface: free iface=0x7f98e410
>>> ubuntu@arm:~$
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/84788d1e-c743-4f9d-97cd-8b85fcef2a94%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/00bf0b87-bbe8-44ec-bc66-381cfd4cde4f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@g

Re: [beagleboard] eQEP Quadrature detector

[evilwulfie]

if you have it working why upgrade ?
do you need a feature on bone 50 ?

On 5/19/2016 5:57 AM, Wim Hellenthal wrote:
>
> Please help,
>
>  
>
> I've already posted a mail before but got no reaction. I'm desperately
> looking for support. I have a running quadrature detector using pin
> P8_12 and P8_11 (eqep2), see the attached dts file. The code I’m using
> is based on accessing the eQEP register using memory mapped IO (mmio).
>
>  
>
> I’ve have used the detector without any problems on a BBB board
> running the following debian version:
>
> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014
> armv7l GNU/Linux
>
>  
>
> Now I’m trying to run exactly the same code on a newer debian version.
> This is not working anymore!  I managed to download and install
> the following debian version (among some other versions):
>
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13
> 13:24:52 UTC 2014 armv7l GNU/Linux
>
>  
>
> Note that I installed the bone50 version on a different BBB board. I
> don’t want to mess up the correct working bone47 board. Both board
> have 4G eMMC memory (revision - C)
>
> What I notice is that the folder structure for both version is different:
>
>
>
> For Bone47 it is:  /sys/devices/ocp.3/48304000.epwmss
>
> For Bone50 it is:
>  /sys/devices/ocp.3/48304000.epwmss/48304180.eqep
>
>
> Bone47; No means to read the position and the like.
>
> Bone50; Reading the position using *cat position* alway return zero,
> this is also what I see running the mmio code.
>
>
> So what could be the cause that the quadrature detector is no longer
> working on debian version higher than 3.8.13-bone47? At least the
> folder structure is different. Is this a kernel driver issue? Do I
> have to redefine the .dts file? Any help would be highly appreciated.
>
>  
>
> Best regards,
>
> Wim
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5bcb57fb-0cc5-42a2-b861-2ed059a5970f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cdcef9b0-8ef8-d4b2-d734-66eccfb04fa5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Shaurabh Kumar Singh]

Yes i have already tried activating the serial ports as shown in the link 
before. Still it did not seem to work.

On Wednesday, May 18, 2016 at 4:46:20 PM UTC-4, Shaurabh Kumar Singh wrote:
>
> I have been trying to communicate with a CNC machine through RS 232 to the 
> Beaglebone Black. 
> Following are the Serial Port settings at the Machine
> Baudrate=9600
> Databits=8
> Stopbits=1
> Parity=None
> CR only
>
> When i tried connecting it to my desktop(windows 10-using python) 
> directly(done without using BBB) and i set the same parameters i got the 
> response from the machine like i had expected.
>
> Although, when done using the BBB (debian), also using python, i just 
> received the string command i sent to the machine. Following is the python 
> code.
>
> import Adafruit_BBIO.UART as UART
>
> import serial, string
>
> UART.setup("UART1")
> with serial.Serial(port="/dev/ttyO0",baudrate=9600,timeout=2) as ser: #i 
> also tried mentioning databits and stopbits and other parameters but they 
> still did not work
> ser.write(b"Q100\r")
> c=ser.readline().decode("utf-8","ignore")
> print(c)
> ser.close()
>
> This works all fine in windows(gives the serial no. as the output) but 
> simply gives back Q100as output (same as input).
>
> I was wondering if it could be due to the different OS on my laptop and 
> BBB. Should i try installing windows ce on the BBB and work with that?
>
>
> Thank you
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e6ef68e3-9136-4867-9b99-e3170f17edc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[Super Twang]

@Lachlan
Thanks for the info Lachlan.  

Re: Supercap reliability…
My basic understanding is that if you design with supercaps for a “Everyday” 
(ie not too hardcore) indoor use case, and keep them within some pretty 
obtainable operating conditions they effectively last forever.  Obviously 
there’s some ambiguity (“everyday” “pretty obtainable”, “effectively”) in the 
prior assertion, but...

My particular use case — indoor temps but in a wall, 5v power — might see a 
temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking about 
would have to be a pretty harsh/industrial environment, no?

Does anyone (who has done it, or knows how) have a sense of how straightforward 
it is to achieve a supercap-based system design that keeps the components in a 
range that’d keep them healthy for “Effectively forever?”  ie 20k+ cycles? 
(better than bats) 100k+? (effectively forever) Or, do the requirements we’re 
looking at for a basic, indoor, power system really push the supercaps into the 
“Quickly-used-up” zone?

Best,
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[pierluigi desimone]

I am curious too

ciao

On 19 May 2016 at 10:44,  wrote:

> Just curious.
> What is the current state of affairs?
>
> My order at mouser dot com gives me a dispatch Date first of august.
>
> Patrick
>
>
> Op donderdag 7 april 2016 03:12:46 UTC+2 schreef Gerald:
>>
>> Yes indeed.
>>
>> Gerald
>>
>>
>> On Wed, Apr 6, 2016 at 7:51 PM, Dennis Lee Bieber 
>> wrote:
>>
>>> On Wed, 6 Apr 2016 08:54:24 -0500, Gerald Coley
>>>  declaimed the following:
>>>
>>> >1. We expect PCBs here in another week. 4/13/2016
>>> >2. 1 week for assembly.4/20/2015
>>> >3. 1 week for test and bring up. 4/27/2016
>>> >4. 1 week for FCC testing 5/4/2016
>>> >5. First 500 boards shipping 2 weeks later. 5/18/2016
>>> ... contingent on passing FCC, I'm sure
>>> --
>>> Wulfraed Dennis Lee Bieber AF6VN
>>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>> gco...@emprodesign.com
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/UHe7I-gFAK0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5b5596ae-6d41-4b07-a231-bf52cc0ab39e%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
 ---
Dr. Pierluigi  De Simone

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAAnx-bR7u9fWt5bq%2BenUidoCZLnT3EP2X%3DQGxFh0G87DW3A0sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Release date update?

[Gerald Coley]

http://elinux.org/Beagleboard:BeagleBoard-X15

Gerald


On Thu, May 19, 2016 at 6:41 AM, pierluigi desimone <
pierluigi.desim...@gmail.com> wrote:

> I am curious too
>
> ciao
>
> On 19 May 2016 at 10:44,  wrote:
>
>> Just curious.
>> What is the current state of affairs?
>>
>> My order at mouser dot com gives me a dispatch Date first of august.
>>
>> Patrick
>>
>>
>> Op donderdag 7 april 2016 03:12:46 UTC+2 schreef Gerald:
>>>
>>> Yes indeed.
>>>
>>> Gerald
>>>
>>>
>>> On Wed, Apr 6, 2016 at 7:51 PM, Dennis Lee Bieber 
>>> wrote:
>>>
 On Wed, 6 Apr 2016 08:54:24 -0500, Gerald Coley
  declaimed the following:

 >1. We expect PCBs here in another week. 4/13/2016
 >2. 1 week for assembly.4/20/2015
 >3. 1 week for test and bring up. 4/27/2016
 >4. 1 week for FCC testing 5/4/2016
 >5. First 500 boards shipping 2 weeks later. 5/18/2016
 ... contingent on passing FCC, I'm sure
 --
 Wulfraed Dennis Lee Bieber AF6VN
 wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>> gco...@emprodesign.com
>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/UHe7I-gFAK0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/5b5596ae-6d41-4b07-a231-bf52cc0ab39e%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>  ---
> Dr. Pierluigi  De Simone
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAAnx-bR7u9fWt5bq%2BenUidoCZLnT3EP2X%3DQGxFh0G87DW3A0sg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BdVvk9WtKEVsxZ207nGBMMjX%2B4P0H5d9zdh0mPnEvVP0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] spontaneous reboot issues bbb, jessie 8.4 console image of 4/7/2016, 4.4.9 -bone-rt-r10 LTS kernel

[Super Twang]

PS. Is this the best place to put bug/issue reports?  I believe this 
relates to the core image & kernel of a Jessie LTS release.

---

I'm seeing semi-regular spontaneous reboots on the BBB.  Here's what I'm 
seeing:

Running 'top', the "Mem Buffers" field, (4th line, far right), is steadily 
increasing until the system reboots at around (41180 buffers).

Anyhow, since I'm going after max stability, this is of concern to me, so 
I've been doing a little testing.

I'm not entirely sure what I'm looking for, but since I'm not running any 
of my own apps in this setup, I'm hoping the results might be useful for 
someone else?


I have logs available from

vmstat -s K -n 1 >> logfile

as well as a screengrab at time of fail of 

'top'

and

'slabtop'

Let me know if you have any insights or would like the logs.  I still have 
the image and am happy to run other tests if it'll help.  
In the meantime, I'm going to revert to a Wheezy console image and hope to 
find more stability there.

Best,
Dave

- setup is below

Setup:

Running from image:  RCN's jessie 8.4 console image of 4/7/2016  (with some 
packages removed, and a developer environment installed)

Kernel:  4.4.9 -bone-rt-r10 kernel

Running from SDCard

ssh'ed in via DCHP connected ethernet, most recently capturing vmstat to a 
log file.



PS.  Under a different testing scenario where I am running my own http 
server/app, I see strange behavior too.  I can say that my app has been 
extensively tested for leaks, etc, BUT can't rule out that it is my own app 
causing the issues when I am running it.   Nonetheless, maybe the 
strangeness will help dignose the above issue, so I'm including it here.

The strangeness I'm seeing is this:  There is a 24 hour recurring pattern 
to the reboots.In the log below, I'm the number to the right of 
"Startup" is "seconds since last startup".

Any idea what this might be???  Logfile rotation?  Some kind of cron-job 
interference?

2016-05-17 07:36:14: Startup   1566731504* 

2016-05-17 11:57:11: Startup   15657** 

2016-05-17 14:21:10: Startup8639** 

2016-05-17 16:20:27: Startup7157** 

2016-05-17 17:22:41: Startup3734** 

2016-05-17 18:23:23: Startup3642** 

2016-05-17 19:24:06: Startup3643** 

2016-05-17 20:25:33: Startup3687** 

2016-05-17 21:26:16: Startup3643** 

2016-05-17 22:27:00: Startup3644** 

2016-05-17 23:27:41: Startup3641** 

2016-05-18 00:28:24: Startup3643** 

2016-05-18 01:30:36: Startup3732** 

2016-05-18 02:29:06: Startup3510** 

2016-05-18 03:17:03: Startup2877** 

2016-05-18 03:21:32: Startup 269** 

2016-05-18 03:25:59: Startup 267** 

2016-05-18 03:30:27: Startup 268** 

2016-05-18 03:34:54: Startup 267** 

2016-05-18 07:25:51: Startup   13857** 

2016-05-18 11:22:51: Startup   14220** 

2016-05-18 12:51:18: Startup5307** 

2016-05-18 13:51:59: Startup3641** 

2016-05-18 14:54:13: Startup3734** 

2016-05-18 15:55:42: Startup3689** 

2016-05-18 16:56:25: Startup3643** 

2016-05-18 17:57:54: Startup3689** 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d9d73516-35b8-4673-96b5-e8dc9bef93d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] spontaneous reboot issues bbb, jessie 8.4 console image of 4/7/2016, 4.4.9 -bone-rt-r10 LTS kernel

[Robert Nelson]

That's odd...

http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-6.log

Double check your power supply..

On May 19, 2016 11:34 AM, "Super Twang"  wrote:
>
>
> PS. Is this the best place to put bug/issue reports?  I believe this
relates to the core image & kernel of a Jessie LTS release.
>
> ---
>
> I'm seeing semi-regular spontaneous reboots on the BBB.  Here's what I'm
seeing:
>
> Running 'top', the "Mem Buffers" field, (4th line, far right), is
steadily increasing until the system reboots at around (41180 buffers).
>
> Anyhow, since I'm going after max stability, this is of concern to me, so
I've been doing a little testing.
>
> I'm not entirely sure what I'm looking for, but since I'm not running any
of my own apps in this setup, I'm hoping the results might be useful for
someone else?
>
>
> I have logs available from
>
> vmstat -s K -n 1 >> logfile
>
> as well as a screengrab at time of fail of
>
> 'top'
>
> and
>
> 'slabtop'
>
> Let me know if you have any insights or would like the logs.  I still
have the image and am happy to run other tests if it'll help.
> In the meantime, I'm going to revert to a Wheezy console image and hope
to find more stability there.
>
> Best,
> Dave
>
> - setup is below
>
> Setup:
>
> Running from image:  RCN's jessie 8.4 console image of 4/7/2016  (with
some packages removed, and a developer environment installed)
>
> Kernel:  4.4.9 -bone-rt-r10 kernel
>
> Running from SDCard
>
> ssh'ed in via DCHP connected ethernet, most recently capturing vmstat to
a log file.
>
>
>
> PS.  Under a different testing scenario where I am running my own http
server/app, I see strange behavior too.  I can say that my app has been
extensively tested for leaks, etc, BUT can't rule out that it is my own app
causing the issues when I am running it.   Nonetheless, maybe the
strangeness will help dignose the above issue, so I'm including it here.
>
> The strangeness I'm seeing is this:  There is a 24 hour recurring pattern
to the reboots.In the log below, I'm the number to the right of
"Startup" is "seconds since last startup".
>
> Any idea what this might be???  Logfile rotation?  Some kind of cron-job
interference?
>
> 2016-05-17 07:36:14: Startup   1566731504*
>
> 2016-05-17 11:57:11: Startup   15657**
>
> 2016-05-17 14:21:10: Startup8639**
>
> 2016-05-17 16:20:27: Startup7157**
>
> 2016-05-17 17:22:41: Startup3734**
>
> 2016-05-17 18:23:23: Startup3642**
>
> 2016-05-17 19:24:06: Startup3643**
>
> 2016-05-17 20:25:33: Startup3687**
>
> 2016-05-17 21:26:16: Startup3643**
>
> 2016-05-17 22:27:00: Startup3644**
>
> 2016-05-17 23:27:41: Startup3641**
>
> 2016-05-18 00:28:24: Startup3643**
>
> 2016-05-18 01:30:36: Startup3732**
>
> 2016-05-18 02:29:06: Startup3510**
>
> 2016-05-18 03:17:03: Startup2877**
>
> 2016-05-18 03:21:32: Startup 269**
>
> 2016-05-18 03:25:59: Startup 267**
>
> 2016-05-18 03:30:27: Startup 268**
>
> 2016-05-18 03:34:54: Startup 267**
>
> 2016-05-18 07:25:51: Startup   13857**
>
> 2016-05-18 11:22:51: Startup   14220**
>
> 2016-05-18 12:51:18: Startup5307**
>
> 2016-05-18 13:51:59: Startup3641**
>
> 2016-05-18 14:54:13: Startup3734**
>
> 2016-05-18 15:55:42: Startup3689**
>
> 2016-05-18 16:56:25: Startup3643**
>
> 2016-05-18 17:57:54: Startup3689**
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/d9d73516-35b8-4673-96b5-e8dc9bef93d7%40googlegroups.com
.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhLXvvT9ATJCir4et-N42duXzCPginVdWdZZ0nnp1sGqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Best (most-stable) console image to start from?

[Super Twang]

Can anyone recommend the most stable version of RCN's console images on 
which to base an embedded device that uses the PRU (uio_pruss)?

>From what I understand there was incompatibility with the PRU somewhere 
between 3.8 - 4.1.

I'd like to go back in time (probably to a Wheezy install) to a point of 
known good stability (ie no reboots caused by OS/hardware), but I'm not 
sure where to land.

I most recently tried:

Jessie 8.4 console image of 4/7/2016
Kernel:  4.4.9 -bone-rt-r10 kernel

but am seeing spontaneous reboots (even not running my own SW).  

Thanks for any guidance you can provide!

Best,
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b15f8412-5b5b-43c5-b081-7e6a0c722bf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP Quadrature detector

[Wim Hellenthal]

On Thursday, May 19, 2016 at 3:29:22 PM UTC+2, Wulf Man wrote:
> if you have it working why upgrade ?
> 
>   do you need a feature on bone 50 ?
> 
>   
> 
>   On 5/19/2016 5:57 AM, Wim Hellenthal wrote:
> 
> 
> 
>   
> 
> 
> 
>   
>   
> Please help,
>   
>   
>   
>  
>   
>   
>   
> I've already posted a
> mail before but got no reaction. I'm
> desperately looking for support. I have a running
> quadrature detector using pin
> P8_12 and P8_11 (eqep2), see the attached dts file. The
> code I’m using is based
> on accessing the eQEP register using memory mapped IO
> (mmio). 
>   
>   
>   
>  
>   
>   
>   
> I’ve have used the
> detector without any problems on a BBB board
> running the following debian version:
>   
>   
>   
> Linux beaglebone
> 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC
> 2014 armv7l GNU/Linux
>   
>   
>   
>  
>   
>   
>   
> Now I’m trying to run
> exactly the same code on a newer debian
> version. This is not working anymore!  I managed to
> download and install the following debian version
> (among some other versions):
>   
>   
>   
>     Linux
> beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC
> 2014 armv7l GNU/Linux
>   
>   
>   
>  
>   
>   
>   
> Note that I installed
> the bone50 version on a different BBB
> board. I don’t want to mess up the correct working
> bone47 board. Both board have 4G eMMC memory (revision -
> C) 
>   
>   
>   
> What I notice is that
> the folder structure for both version is
> different: 
>   
>   
>   
>     
>   
>   
>   
>     For
> Bone47 it
> is:  /sys/devices/ocp.3/48304000.epwmss
>   
>   
>   
>   
>     For
> Bone50
> it is:  /sys/devices/ocp.3/48304000.epwmss/48304180.eqep
>   
>   
>   
> 
> 
>   
>   
> Bone47; No means to
> read the position and the like. 
>   
> Bone50; Reading the
> position using cat position alway
> return zero, this is also what I see running the mmio
> code. 
>   
> 
> 
>   
>   
>   
>   
> So what could be the
> cause that the quadrature detector is no
> longer working on debian version higher than
> 3.8.13-bone47? At least the folder
> structure is different. Is this a kernel driver issue?
> Do I have to redefine
> the .dts file? Any help would be highly appreciated. 
>   
>   
>   
>  
>   
>   
>   
> Best regards,
>   
>   
>   
> Wim
>   
>   
>   
>   -- 
> 
>   For more options, visit http://beagleboard.org/discuss
> 
>   --- 
> 
>   You received this message because you are subscribed to the Google
>   Groups "BeagleBoard" group.
> 
>   To unsubscribe from this group and stop receiving emails from it,
>   send an email to beagleboard...@googlegroups.com.
> 
>   To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5bcb57fb-0cc5-42a2-b861-2ed059a5970f%40googlegroups.com.
> 
>   For more options, visit https://groups.google.com/d/optout.

I understand your question. But unfortunatly all New puchased boards carry a 
version higher then bone47 that don't work either 

Regards Wim

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/66be5cb7-ba94-4c56-b749-4eebb8f71397%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black RTC Wake Alarms

[francis ... @gmail.com]

I am also looking for this functionnality for the kernel 3.8 or 3.14.

On Friday, April 22, 2016 at 10:36:06 AM UTC-4, darren@gmail.com wrote:
>
>
> On Thursday, April 21, 2016 at 6:26:19 PM UTC-4, William Hermans wrote:
>>
>> I can tell you that using kernel 4.1.x 
>> https://www.linux.com/learn/wake-linux-rtc-alarm-clock works. I'm not 
>> sure that rtc wake timer is related to the one you're asking. However, I 
>> can tell you that once the main am335x processor loses power, or the 
>> ability to act from being in sleep mode, the RTC on the processor die will 
>> no longer function correctly. There has been some discussion on these 
>> forums about this in the past, and I do believe there was actually an 
>> errata on this as well.
>>
>>
> I am just trying to put the system in the "mem" sleep/suspend state and 
> have a timer wake the system back up. Using the rtcwake command (and "mem" 
> mode) does work, but when I create a timer with timerfd (instead of using 
> the /dev/rtc0 device directly like rtcwake does) it does not work. It seems 
> like there might be a wake source or something missing.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/603d798f-68f0-47a6-93d6-96ac9ebeea0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] spontaneous reboot issues bbb, jessie 8.4 console image of 4/7/2016, 4.4.9 -bone-rt-r10 LTS kernel

[Super Twang]

Robert,

You make a good point.  Maybe a brownout/blackout caused it.  We had a tstorm 
roll through here last night, and I’m not running power from a UPS,   I wish 
there was someway to catch a spontaneous power loss in the logs so I could 
differentiate that out, but the syslog shows nothing in these cases.  I’ll try 
again with (more) stable power.

Is it normal for the buffer count to steadily increase like I’m seeing?  Could 
it be my own stat logging that is causing it?  Maybe I’m doing something and 
just not seeing it straight, but I’m trying to have as minimal an impact as I 
can on the running system.

Thanks for your thoughts.

Best,
ST

PS. Out of curiosity, how many machines are in your testing farm?  Do you have 
a photo?  I’ve got a whopping 2. :)


> On May 19, 2016, at 11:37 AM, Robert Nelson  wrote:
> 
> That's odd...
> 
> http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-6.log 
> 
> Double check your power supply.. 
> 
> On May 19, 2016 11:34 AM, "Super Twang"  > wrote:
> >
> >
> > PS. Is this the best place to put bug/issue reports?  I believe this 
> > relates to the core image & kernel of a Jessie LTS release.
> >
> > ---
> >
> > I'm seeing semi-regular spontaneous reboots on the BBB.  Here's what I'm 
> > seeing:
> >
> > Running 'top', the "Mem Buffers" field, (4th line, far right), is steadily 
> > increasing until the system reboots at around (41180 buffers).
> >
> > Anyhow, since I'm going after max stability, this is of concern to me, so 
> > I've been doing a little testing.
> >
> > I'm not entirely sure what I'm looking for, but since I'm not running any 
> > of my own apps in this setup, I'm hoping the results might be useful for 
> > someone else?
> >
> >
> > I have logs available from
> >
> > vmstat -s K -n 1 >> logfile
> >
> > as well as a screengrab at time of fail of 
> >
> > 'top'
> >
> > and
> >
> > 'slabtop'
> >
> > Let me know if you have any insights or would like the logs.  I still have 
> > the image and am happy to run other tests if it'll help.  
> > In the meantime, I'm going to revert to a Wheezy console image and hope to 
> > find more stability there.
> >
> > Best,
> > Dave
> >
> > - setup is below
> >
> > Setup:
> >
> > Running from image:  RCN's jessie 8.4 console image of 4/7/2016  (with some 
> > packages removed, and a developer environment installed)
> >
> > Kernel:  4.4.9 -bone-rt-r10 kernel
> >
> > Running from SDCard
> >
> > ssh'ed in via DCHP connected ethernet, most recently capturing vmstat to a 
> > log file.
> >
> >
> >
> > PS.  Under a different testing scenario where I am running my own http 
> > server/app, I see strange behavior too.  I can say that my app has been 
> > extensively tested for leaks, etc, BUT can't rule out that it is my own app 
> > causing the issues when I am running it.   Nonetheless, maybe the 
> > strangeness will help dignose the above issue, so I'm including it here.
> >
> > The strangeness I'm seeing is this:  There is a 24 hour recurring pattern 
> > to the reboots.In the log below, I'm the number to the right of 
> > "Startup" is "seconds since last startup".
> >
> > Any idea what this might be???  Logfile rotation?  Some kind of cron-job 
> > interference?
> >
> > 2016-05-17 07:36:14: Startup   1566731504* 
> >
> > 2016-05-17 11:57:11: Startup   15657** 
> >
> > 2016-05-17 14:21:10: Startup8639** 
> >
> > 2016-05-17 16:20:27: Startup7157** 
> >
> > 2016-05-17 17:22:41: Startup3734** 
> >
> > 2016-05-17 18:23:23: Startup3642** 
> >
> > 2016-05-17 19:24:06: Startup3643** 
> >
> > 2016-05-17 20:25:33: Startup3687** 
> >
> > 2016-05-17 21:26:16: Startup3643** 
> >
> > 2016-05-17 22:27:00: Startup3644** 
> >
> > 2016-05-17 23:27:41: Startup3641** 
> >
> > 2016-05-18 00:28:24: Startup3643** 
> >
> > 2016-05-18 01:30:36: Startup3732** 
> >
> > 2016-05-18 02:29:06: Startup3510** 
> >
> > 2016-05-18 03:17:03: Startup2877** 
> >
> > 2016-05-18 03:21:32: Startup 269** 
> >
> > 2016-05-18 03:25:59: Startup 267** 
> >
> > 2016-05-18 03:30:27: Startup 268** 
> >
> > 2016-05-18 03:34:54: Startup 267** 
> >
> > 2016-05-18 07:25:51: Startup   13857** 
> >
> > 2016-05-18 11:22:51: Startup   14220** 
> >
> > 2016-05-18 12:51:18: Startup5307** 
> >
> > 2016-05-18 13:51:59: Startup3641** 
> >
> > 2016-05-18 14:54:13: Startup3734** 
> >
> > 2016-05-18 15:55:42: Startup3689*  

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

It may not be out door's.. the electronics/computer's may be inside near a
heat source,
I having seen electronics covered up by the end user's many times. (how
many routers have you seen under
a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
ventilation hole's fill with dust, cat hair etc.
it's not just out door's  which may provide and nasty environment.
The second problem is super cap's have high internal resistance, which
limit's how much current you can pull
from them.  Problem there is problem is how much of the capacity of the
super cap are you using ?
a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
reg may only give you 4.3 volts before
the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
of the super capacity you are using.
And to get around that, you need a SEPIC switching reg, and of course your
drawing big currents once you start drooping to 1 or 2 volts of the super
cap.  So the cost of having a Electro  running at 40 or 50V,  where you will
get almost all of it's capacity is not a bad trade off, when you see that
you will have even bigger problem with supper caps and extracting there
full capacity.   And you will be switch much higher currents to get your
3.3V's from it.

Lachlan


On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might see
> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
> about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Getting Bootchart setup on Debian 8.3

[John Baker]

My apologies to All: I'm an interloper. Actually I'm using Debian Wheezy 
and my problem is not related to bootchart. I hitched onto this thread, 
suggested by Drew Fustini in the Adafruit forum. 

I have an Adafruit DS3231 Real Time Clock module attached to my BBB. Debian 
is delaying for one minute to read the DS3231's clock time and I would like 
to eliminate that one minute delay. I suspect that Debian is trying to go 
through the Internet to read the time from ntpdate or whatever and gives up 
after a minute, finally reading the clock data from the DS3231 module.

FWIW, I checked the status of the systemd-timesyncd service and found that 
it's "inactive (dead)."

Thanks,
John

On Thursday, May 19, 2016 at 5:08:51 AM UTC-7, Alex wrote:
>
> As Robert told u, you need to disable the service
> systemd-timesyncd:
>
> systemctl disable systemd-timesyncd
>
> Le jeu. 19 mai 2016 13:27, John Baker > a 
> écrit :
>
>> Thanks Micka.
>>
>> I just now tried that and putty.exe said that ntp isn't installed, so not 
>> removed, but I'll bet it's gotta be something like that. Maybe something 
>> for the Internet connection.
>>
>> John
>>
>> On 5/18/2016 8:33 PM, Micka wrote:
>>
>> sudo apt-get remove ntp
>>
>> Le mer. 18 mai 2016 23:53, John Baker < 
>> bakerengi...@gmail.com > a écrit :
>>
>>> Robert:
>>> What script is trying to read the clock data from ntp? I have an 
>>> Adafruit DS3231 for the Real Time Clock and the BBB is taking a minute 
>>> before it gets the clock from the DS3231 so I suspect some script is trying 
>>> to read the ntp clock data and holding up the read of my DS3231 clock. Es 
>>> posible?
>>> John
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> 
>>> https://groups.google.com/d/msgid/beagleboard/66884716-e25b-412e-98f1-97870f8f7127%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>>
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/Rtn0sS_z9DA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> 
>> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DQWMYfn_4Ox9gGox9HYjtPC8Z7HTNbKESAevfEseYEA%40mail.gmail.com
>> .
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/af3c4179-e373-0cc9-4665-b8bbf5b91bfb%40ieee.org
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7f317a3b-165a-44b0-96a3-b2b206631d9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

@Super Twang,

Sure super caps are usable, there are a few on these groups who do use them
in place of a battery. Last time I personally looked though, cost was very
prohibitive. For instance:

http://www.ebay.com/itm/like/262291173781?lpid=82&chn=ps&ul_noapp=true

$16.50 + $5.50 shipping each ? How many farads do we need to keep the board
up for 30-60 seconds ? But let's assume two of these in series( because
2.7v is not enough ).

versus something like this:

http://www.ebay.com/itm/Lipo-Battery-Replacement-battery-for-808-18-Car-Key-Camera-Mini-DVR-60-minutes-/251600381055?hash=item3a948d247f:g:vu4AAOSwRLZT1MJd

Anyway, I did not look too long, but lower capacity super caps did not sem
to drop in price much. 120 farad caps seemed to be pretty close in price
too.

So, for a one off solution maybe not too much of a big deal, but for many,
many systems. That cost is going to be far too high.

On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might see
> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
> about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrevWnDi-%2BAYvOt%3D00ws4QeuXyAQu5ejFE7ywqUY%3DYJ9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

Oh and for those worried about the LiPO chemistry . . .
http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg

Problem is, you need three, maybe four of these. But cost would be ~$6-$8.
Additionally 2200mah is a bit much if all you're going ot do is shutdown
right away. So perhaps the AA cell equivelent, and those would cost less.
SubC is the cell type typically used in cordless drill packs . . .

On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas  wrote:

> It may not be out door's.. the electronics/computer's may be inside near a
> heat source,
> I having seen electronics covered up by the end user's many times. (how
> many routers have you seen under
> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
> ventilation hole's fill with dust, cat hair etc.
> it's not just out door's  which may provide and nasty environment.
> The second problem is super cap's have high internal resistance, which
> limit's how much current you can pull
> from them.  Problem there is problem is how much of the capacity of the
> super cap are you using ?
> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
> reg may only give you 4.3 volts before
> the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
> of the super capacity you are using.
> And to get around that, you need a SEPIC switching reg, and of course your
> drawing big currents once you start drooping to 1 or 2 volts of the super
> cap.  So the cost of having a Electro  running at 40 or 50V,  where you will
> get almost all of it's capacity is not a bad trade off, when you see that
> you will have even bigger problem with supper caps and extracting there
> full capacity.   And you will be switch much higher currents to get your
> 3.3V's from it.
>
> Lachlan
>
>
> On Thu, May 19, 2016 at 8:33 AM, Super Twang  wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might see
>> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
>> about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
>> Best,
>> ST
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqK7yJ6yEtajxN97w_%3DY3u-fMie4DT%2B3apOqrizpzBpKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Best (most-stable) console image to start from?

[William Hermans]

No one can make this determination for you.
 As there is no "one size fits all" image.

On Thu, May 19, 2016 at 9:50 AM, Super Twang  wrote:

>
> Can anyone recommend the most stable version of RCN's console images on
> which to base an embedded device that uses the PRU (uio_pruss)?
>
> From what I understand there was incompatibility with the PRU somewhere
> between 3.8 - 4.1.
>
> I'd like to go back in time (probably to a Wheezy install) to a point of
> known good stability (ie no reboots caused by OS/hardware), but I'm not
> sure where to land.
>
> I most recently tried:
>
> Jessie 8.4 console image of 4/7/2016
> Kernel:  4.4.9 -bone-rt-r10 kernel
>
> but am seeing spontaneous reboots (even not running my own SW).
>
> Thanks for any guidance you can provide!
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/b15f8412-5b5b-43c5-b081-7e6a0c722bf9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORo09%2B9gEQmqF95eiCxh_ZnRO1zmvOS_7W77Mwu%3De6abaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

NiCad's are bad news..  They are extremely toxic, and nasty.
I would not use them,   Have a look at
https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
much better option.

Lachlan



On Thu, May 19, 2016 at 10:38 AM, William Hermans  wrote:

> Oh and for those worried about the LiPO chemistry . . .
> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>
> Problem is, you need three, maybe four of these. But cost would be ~$6-$8.
> Additionally 2200mah is a bit much if all you're going ot do is shutdown
> right away. So perhaps the AA cell equivelent, and those would cost less.
> SubC is the cell type typically used in cordless drill packs . . .
>
> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas  wrote:
>
>> It may not be out door's.. the electronics/computer's may be inside near
>> a heat source,
>> I having seen electronics covered up by the end user's many times. (how
>> many routers have you seen under
>> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
>> ventilation hole's fill with dust, cat hair etc.
>> it's not just out door's  which may provide and nasty environment.
>> The second problem is super cap's have high internal resistance, which
>> limit's how much current you can pull
>> from them.  Problem there is problem is how much of the capacity of the
>> super cap are you using ?
>> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or liner
>> reg may only give you 4.3 volts before
>> the reg start's dropping the 3.3v power rail.   So there may be only 0.7V
>> of the super capacity you are using.
>> And to get around that, you need a SEPIC switching reg, and of course
>> your drawing big currents once you start drooping to 1 or 2 volts of the
>> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
>> you will
>> get almost all of it's capacity is not a bad trade off, when you see that
>> you will have even bigger problem with supper caps and extracting there
>> full capacity.   And you will be switch much higher currents to get your
>> 3.3V's from it.
>>
>> Lachlan
>>
>>
>> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
>> wrote:
>>
>>> @Lachlan
>>> Thanks for the info Lachlan.
>>>
>>> Re: Supercap reliability…
>>> My basic understanding is that if you design with supercaps for a
>>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>>> pretty obtainable operating conditions they effectively last forever.
>>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>>> “effectively”) in the prior assertion, but...
>>>
>>> My particular use case — indoor temps but in a wall, 5v power — might
>>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>>> talking about would have to be a pretty harsh/industrial environment, no?
>>>
>>> Does anyone (who has done it, or knows how) have a sense of how
>>> straightforward it is to achieve a supercap-based system design that keeps
>>> the components in a range that’d keep them healthy for “Effectively
>>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>>> Or, do the requirements we’re looking at for a basic, indoor, power system
>>> really push the supercaps into the “Quickly-used-up” zone?
>>>
>>> Best,
>>> ST
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https:/

Re: [beagleboard] Getting Bootchart setup on Debian 8.3

[William Hermans]

>
> *My apologies to All: I'm an interloper. Actually I'm using Debian Wheezy
> and my problem is not related to bootchart. I hitched onto this thread,
> suggested by Drew Fustini in the Adafruit forum. *
>
> *I have an Adafruit DS3231 Real Time Clock module attached to my BBB.
> Debian is delaying for one minute to read the DS3231's clock time and
> I would like to eliminate that one minute delay. I suspect that Debian is
> trying to go through the Internet to read the time from ntpdate or whatever
> and gives up after a minute, finally reading the clock data from
> the DS3231 module.*
>
> *FWIW, I checked the status of the systemd-timesyncd service and found
> that it's "inactive (dead)."*
>
> *Thanks,*
> *John*
>

John,

Maybe helpful for you, maybe not. But you could look into the wheezy
package fake-hwclock, which keeps time as close as possible to accurate
time between reboots. Which would then make that one minute delay at least
bearable.

The problem I'm thinking you're running into here is that it takes a while
for the OS to come up. So until the system is read to take care of reading
the real time clock . . .

Perhaps you could find, or write a kernel module that loads time from the
rtc at early boot ? But non of this is anything I'v personally had hands on
with, except fake-hwclock.

On Thu, May 19, 2016 at 10:33 AM, John Baker 
wrote:

> My apologies to All: I'm an interloper. Actually I'm using Debian Wheezy
> and my problem is not related to bootchart. I hitched onto this thread,
> suggested by Drew Fustini in the Adafruit forum.
>
> I have an Adafruit DS3231 Real Time Clock module attached to my BBB.
> Debian is delaying for one minute to read the DS3231's clock time and
> I would like to eliminate that one minute delay. I suspect that Debian is
> trying to go through the Internet to read the time from ntpdate or whatever
> and gives up after a minute, finally reading the clock data from
> the DS3231 module.
>
> FWIW, I checked the status of the systemd-timesyncd service and found that
> it's "inactive (dead)."
>
> Thanks,
> John
>
> On Thursday, May 19, 2016 at 5:08:51 AM UTC-7, Alex wrote:
>>
>> As Robert told u, you need to disable the service
>> systemd-timesyncd:
>>
>> systemctl disable systemd-timesyncd
>>
>> Le jeu. 19 mai 2016 13:27, John Baker  a écrit :
>>
>>> Thanks Micka.
>>>
>>> I just now tried that and putty.exe said that ntp isn't installed, so
>>> not removed, but I'll bet it's gotta be something like that. Maybe
>>> something for the Internet connection.
>>>
>>> John
>>>
>>> On 5/18/2016 8:33 PM, Micka wrote:
>>>
>>> sudo apt-get remove ntp
>>>
>>> Le mer. 18 mai 2016 23:53, John Baker  a écrit :
>>>
 Robert:
 What script is trying to read the clock data from ntp? I have an
 Adafruit DS3231 for the Real Time Clock and the BBB is taking a minute
 before it gets the clock from the DS3231 so I suspect some script is trying
 to read the ntp clock data and holding up the read of my DS3231 clock. Es
 posible?
 John

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard...@googlegroups.com.
 To view this discussion on the web visit
 
 https://groups.google.com/d/msgid/beagleboard/66884716-e25b-412e-98f1-97870f8f7127%40googlegroups.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>>
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/beagleboard/Rtn0sS_z9DA/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 
>>> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DQWMYfn_4Ox9gGox9HYjtPC8Z7HTNbKESAevfEseYEA%40mail.gmail.com
>>> .
>>>
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/af3c4179-e373-0cc9-4665-b8bbf5b91bfb%40ieee.org
>>> 

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

My point is, there are many different battery chemistry types. Then at some
point if you want to "play" you're going to have to "bargin with the devil"
one way or another.

On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas  wrote:

> NiCad's are bad news..  They are extremely toxic, and nasty.
> I would not use them,   Have a look at
> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
> much better option.
>
> Lachlan
>
>
>
> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
> wrote:
>
>> Oh and for those worried about the LiPO chemistry . . .
>> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>>
>> Problem is, you need three, maybe four of these. But cost would be
>> ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
>> shutdown right away. So perhaps the AA cell equivelent, and those would
>> cost less. SubC is the cell type typically used in cordless drill packs . .
>> .
>>
>> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
>> wrote:
>>
>>> It may not be out door's.. the electronics/computer's may be inside near
>>> a heat source,
>>> I having seen electronics covered up by the end user's many times. (how
>>> many routers have you seen under
>>> a pile of books..  clothing ? ..etc ) then there is fan's breaking,  air
>>> ventilation hole's fill with dust, cat hair etc.
>>> it's not just out door's  which may provide and nasty environment.
>>> The second problem is super cap's have high internal resistance, which
>>> limit's how much current you can pull
>>> from them.  Problem there is problem is how much of the capacity of the
>>> super cap are you using ?
>>> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
>>> liner reg may only give you 4.3 volts before
>>> the reg start's dropping the 3.3v power rail.   So there may be only
>>> 0.7V of the super capacity you are using.
>>> And to get around that, you need a SEPIC switching reg, and of course
>>> your drawing big currents once you start drooping to 1 or 2 volts of the
>>> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
>>> you will
>>> get almost all of it's capacity is not a bad trade off, when you see
>>> that you will have even bigger problem with supper caps and extracting
>>> there full capacity.   And you will be switch much higher currents to get
>>> your 3.3V's from it.
>>>
>>> Lachlan
>>>
>>>
>>> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
>>> wrote:
>>>
 @Lachlan
 Thanks for the info Lachlan.

 Re: Supercap reliability…
 My basic understanding is that if you design with supercaps for a
 “Everyday” (ie not too hardcore) indoor use case, and keep them within some
 pretty obtainable operating conditions they effectively last forever.
 Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
 “effectively”) in the prior assertion, but...

 My particular use case — indoor temps but in a wall, 5v power — might
 see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
 talking about would have to be a pretty harsh/industrial environment, no?

 Does anyone (who has done it, or knows how) have a sense of how
 straightforward it is to achieve a supercap-based system design that keeps
 the components in a range that’d keep them healthy for “Effectively
 forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
 Or, do the requirements we’re looking at for a basic, indoor, power system
 really push the supercaps into the “Quickly-used-up” zone?

 Best,
 ST

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAMkt-MvJMz8Ab_xjC6uXnGWw6maqfEWMYFbJAzO73p0msAxCnQ%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

Two of these
http://www.all-battery.com/LiFePo414500Button-topCylindrical3.2V400mAhRechargeableBattery30225.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c30225&gclid=CPP-mNDa5swCFU1gfgodSBUB1w

Would be good enough for around one hour up time maybe. But honestly I know
nothing of lithium iron phosphate batteries. I'd be "worried" how many
recharge cycles they last before turning to junk.

On Thu, May 19, 2016 at 10:52 AM, William Hermans  wrote:

> My point is, there are many different battery chemistry types. Then at
> some point if you want to "play" you're going to have to "bargin with the
> devil" one way or another.
>
> On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas  wrote:
>
>> NiCad's are bad news..  They are extremely toxic, and nasty.
>> I would not use them,   Have a look at
>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>> much better option.
>>
>> Lachlan
>>
>>
>>
>> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
>> wrote:
>>
>>> Oh and for those worried about the LiPO chemistry . . .
>>> http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg
>>>
>>> Problem is, you need three, maybe four of these. But cost would be
>>> ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
>>> shutdown right away. So perhaps the AA cell equivelent, and those would
>>> cost less. SubC is the cell type typically used in cordless drill packs . .
>>> .
>>>
>>> On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
>>> wrote:
>>>
 It may not be out door's.. the electronics/computer's may be inside
 near a heat source,
 I having seen electronics covered up by the end user's many times. (how
 many routers have you seen under
 a pile of books..  clothing ? ..etc ) then there is fan's breaking,
 air ventilation hole's fill with dust, cat hair etc.
 it's not just out door's  which may provide and nasty environment.
 The second problem is super cap's have high internal resistance, which
 limit's how much current you can pull
 from them.  Problem there is problem is how much of the capacity of the
 super cap are you using ?
 a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
 liner reg may only give you 4.3 volts before
 the reg start's dropping the 3.3v power rail.   So there may be only
 0.7V of the super capacity you are using.
 And to get around that, you need a SEPIC switching reg, and of course
 your drawing big currents once you start drooping to 1 or 2 volts of the
 super cap.  So the cost of having a Electro  running at 40 or 50V,  where
 you will
 get almost all of it's capacity is not a bad trade off, when you see
 that you will have even bigger problem with supper caps and extracting
 there full capacity.   And you will be switch much higher currents to get
 your 3.3V's from it.

 Lachlan


 On Thu, May 19, 2016 at 8:33 AM, Super Twang 
 wrote:

> @Lachlan
> Thanks for the info Lachlan.
>
> Re: Supercap reliability…
> My basic understanding is that if you design with supercaps for a
> “Everyday” (ie not too hardcore) indoor use case, and keep them within 
> some
> pretty obtainable operating conditions they effectively last forever.
> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
> “effectively”) in the prior assertion, but...
>
> My particular use case — indoor temps but in a wall, 5v power — might
> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
> talking about would have to be a pretty harsh/industrial environment, no?
>
> Does anyone (who has done it, or knows how) have a sense of how
> straightforward it is to achieve a supercap-based system design that keeps
> the components in a range that’d keep them healthy for “Effectively
> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
> Or, do the requirements we’re looking at for a basic, indoor, power system
> really push the supercaps into the “Quickly-used-up” zone?
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/F2A9E16C-3FED-44BD-AE07-F928C1477305%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because y

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

Read and you will be supersized how good they are!

Lachlan


On Thu, May 19, 2016 at 10:57 AM, William Hermans  wrote:

> Two of these
> http://www.all-battery.com/LiFePo414500Button-topCylindrical3.2V400mAhRechargeableBattery30225.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c30225&gclid=CPP-mNDa5swCFU1gfgodSBUB1w
>
> Would be good enough for around one hour up time maybe. But honestly I
> know nothing of lithium iron phosphate batteries. I'd be "worried" how many
> recharge cycles they last before turning to junk.
>
> On Thu, May 19, 2016 at 10:52 AM, William Hermans 
> wrote:
>
>> My point is, there are many different battery chemistry types. Then at
>> some point if you want to "play" you're going to have to "bargin with the
>> devil" one way or another.
>>
>> On Thu, May 19, 2016 at 10:46 AM, Lachlan Audas 
>> wrote:
>>
>>> NiCad's are bad news..  They are extremely toxic, and nasty.
>>> I would not use them,   Have a look at
>>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>>> much better option.
>>>
>>> Lachlan
>>>
>>>
>>>
>>> On Thu, May 19, 2016 at 10:38 AM, William Hermans 
>>> wrote:
>>>
 Oh and for those worried about the LiPO chemistry . . .
 http://www.all-battery.com/15pcsnicdsubc2200mahrechargeablebatteryflattop-90626.aspx?utm_source=GoogleShopping&utm_medium=GDF&gdftrk=gdfV26767_a_7c354_a_7c922_a_7c90626&gclid=CJuytLPW5swCFYaTfgod0bgHeg

 Problem is, you need three, maybe four of these. But cost would be
 ~$6-$8. Additionally 2200mah is a bit much if all you're going ot do is
 shutdown right away. So perhaps the AA cell equivelent, and those would
 cost less. SubC is the cell type typically used in cordless drill packs . .
 .

 On Thu, May 19, 2016 at 10:28 AM, Lachlan Audas 
 wrote:

> It may not be out door's.. the electronics/computer's may be inside
> near a heat source,
> I having seen electronics covered up by the end user's many times.
> (how many routers have you seen under
> a pile of books..  clothing ? ..etc ) then there is fan's breaking,
> air ventilation hole's fill with dust, cat hair etc.
> it's not just out door's  which may provide and nasty environment.
> The second problem is super cap's have high internal resistance, which
> limit's how much current you can pull
> from them.  Problem there is problem is how much of the capacity of
> the super cap are you using ?
> a 5V super cap backing up power to a 5v to 3.3v  switching reg,  or
> liner reg may only give you 4.3 volts before
> the reg start's dropping the 3.3v power rail.   So there may be only
> 0.7V of the super capacity you are using.
> And to get around that, you need a SEPIC switching reg, and of course
> your drawing big currents once you start drooping to 1 or 2 volts of the
> super cap.  So the cost of having a Electro  running at 40 or 50V,  where
> you will
> get almost all of it's capacity is not a bad trade off, when you see
> that you will have even bigger problem with supper caps and extracting
> there full capacity.   And you will be switch much higher currents to get
> your 3.3V's from it.
>
> Lachlan
>
>
> On Thu, May 19, 2016 at 8:33 AM, Super Twang 
> wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within 
>> some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might
>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>> talking about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that 
>> keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively 
>> forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power 
>> system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
>> Best,
>> ST
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beag

Re: [beagleboard] Hardware watchdog for BBB

[zamek42]

Hi All,

On 05/19/2016 05:33 PM, Super Twang wrote:

@Lachlan
Thanks for the info Lachlan.

Re: Supercap reliability…
My basic understanding is that if you design with supercaps for a “Everyday” 
(ie not too hardcore) indoor use case, and keep them within some pretty 
obtainable operating conditions they effectively last forever.  Obviously 
there’s some ambiguity (“everyday” “pretty obtainable”, “effectively”) in the 
prior assertion, but...

My particular use case — indoor temps but in a wall, 5v power — might see a 
temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking about 
would have to be a pretty harsh/industrial environment, no?

Does anyone (who has done it, or knows how) have a sense of how straightforward 
it is to achieve a supercap-based system design that keeps the components in a 
range that’d keep them healthy for “Effectively forever?”  ie 20k+ cycles? 
(better than bats) 100k+? (effectively forever) Or, do the requirements we’re 
looking at for a basic, indoor, power system really push the supercaps into the 
“Quickly-used-up” zone?

Yes we have some experience about supercaps.

We have an organ controller which is working two years ago, 
approximately 3-4 on/off  per day. Yes it is an indoor application.
Our second application is an industrial environment with Pandaboard 
which is working since last september approximately 1 on/off per day. It 
is a semi indoor environment.
Our third application is a timelapse camera system with Raspberry ( 
http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early 
of march. It is an outdoor application which is working 7/24.


In other point of view, if you checked the parameters of supercap for 
example 
http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922

you can see:

operating temperature: -40-+60C
Life cycles: 50

A simple NiCd accumulator is much more weight, and its lifecycle is much 
more less, the operating temperature is 0-45C and lifecycle is less than 
1.


So supercap seems to be  ideal for power supply to an embedded system, 
but it needs a little bit complicated controller electronic.

best regards,


--
Zoltan (Zamek) Zidarics
programmer
email:zame...@gmail.com
Self Playing Pipe Organ Systems
http://replayorgan.eu

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Best (most-stable) console image to start from?

[Super Twang]

> On May 19, 2016, at 12:39 PM, William Hermans  wrote:
> No one can make this determination for you. As there is no "one size fits 
> all" image.

@William
I understand.  I’m not asking for that.  I’m already doing a fair bit of add 
and subtract, even starting from a console image, to come up with the best 
image for my own application.  I’m just looking for the gut-check of folks who 
understand the various images and kernels better than I, to know which ones 
might be the best starting point.  (ie those that have issues that might affect 
me, PRU/uio_pruss and others that I don’t know about).  

The process of trying all of the available console images, customizing them and 
subjecting all of them to long-term stability tests, is a painstaking, and long 
process that I am in the middle of.  I have already gleaned what I can from 
forums, etc.  I know I’m not the only one going through this process, so I’m 
just hoping that someone share a few tips to help me reduce the search space.  
With no description of what each image contains, reference of what issues 
popped up for users of them, and no historical record of why new versions were 
rolled (presumably because some problems were fixed, and the newer one is 
better), I don’t have a lot to work with.  Maybe this stuff exists somewhere, 
and I just don’t know where?  If so, point me to it and I’ll keep reading.

Here’s what I’m working with:

“Use an official image” - adds a bunch of stuff that is inappropriate for an 
embedded device (graphical targets, node, cloud9, etc), I don’t know enough 
about what I can safe remove to start from here.

“Use the barefs” - really quite appealing, and I may get there someday, but for 
now, I don’t have a non-virtualized-os linux dev machine.

The best I’ve found so far:

“Use a console image” 

Ok, so I’m using a console image:

“Use the latest image” - exposes me to the potentially lurking issues of the 
cutting edge.  I am uncomfortable with that solution because the level of risk 
is too high for me.

My own reasoning is “Choose a long-term-support variant" (so it will have the 
chance to settle into greater stability).

BUT, I’ve been having a hard time solving stability problems with:
Jessie 8.4 console image of 4/7/2016
Kernel:  4.4.9 -bone-rt-r10 kernel

and know there was a period of uio_pruss issues somewhere in 3.8 - 4.1.  So, my 
thought was to back up to Wheezy.  But, which console image should I start 
with???  Was the latest one the best?

I’m thankful for any input, even if it is to tell me I’m going about this the 
wrong way.  That said, one person telling me I’m doing it wrong is probably not 
going to help, unless they can point me to a better way.  If not, then I’ll 
keep learning as best as I can, and asking for help when I’m stuck.

Best,
ST


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/70D48203-53CF-4CF1-A901-700DA631B6A1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] TPS65217 & Vdd_core 1.125V or 1.2V or 1.1V or .... ?

[John Syne]

I believe the voltage is adjusted based on CPU frequency. If the CPU governor 
is set to dynamic, then the voltage will adjust as the CPU frequency changes.

Regards,
John




> On May 19, 2016, at 12:46 AM, Micka  wrote:
> 
> I already looked at that file and in the starterware there is no line that 
> contain DEFDCD3.
> 
> What I'm saying, is that nowhere I find the same value for DEFDCD3. Some time 
> it's 1.125V, somehwere else it's .95V-1.1V and in the BB_SRM it is 1.1V .
> 
> I'm asking to Gerald, what is the correct value for Vdd_Core ? I think that 
> the correct one is 1.1V. And what is the range ? 0.95V-1.1V ( device tree )
> 
> Le mer. 18 mai 2016 à 22:31, John Syne  > a écrit :
>> On May 18, 2016, at 1:58 AM, Micka > > wrote:
>> 
>> Hi,
>> 
>> In the u-boot 
>> http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;h=4330be64994dc6cbfaff4b865fee44d82f660a3d;hb=HEAD#l255
>>  
>> 
>> 
>> there is those lines :
>> 
>>  255 
>> 
>>  /* Set DCDC3 (CORE) voltage to 1.125V */
>>  256 
>> 
>>  if (tps65217_voltage_update(TPS65217_DEFDCDC3,
>>  257 
>> 
>>  TPS65217_DCDC_VOLT_SEL_1125MV))
>> 
>> 
>> In the device tree there is those lines :
>> 
>>  dcdc3_reg: regulator@2 {
>>  /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% 
>> tolerance */
>>  regulator-name = "vdd_core";
>>  regulator-min-microvolt = <925000>;
>>  regulator-max-microvolt = <115>;
>>  regulator-boot-on;
>>  regulator-always-on;
>>  };
>> 
>> in the starterware from texas + the patch for the bbb I have nothing 
>> concerning the DEFDCD3. 
>> 
>> And finally in the BBB_SRM you have those lines :
>> 
>> The VDD_CORE rail can deliver up to 1.2A at 1.1V. This rail is not 
>> accessible for use anywhere else on the board and only connects to the 
>> processor. This rail is fixed at 1.1V and is not scaled.  
>> 
>> So what is the correct configuration for this output ?
> 
> I believe this is done in bootloader/src/armv7a/am335x/bl_platform.c
> 
> In essence, you have to create a bootable SDCard for Starterware which sets 
> the regulator voltages for you. 
> 
> Regards,
> John
>> 
>> 
>> Micka,
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtm7heTJ45tuWoHt9v1ajBV4XN%2BCk7t%2BfGTn-mrjjJsD%2BA%40mail.gmail.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/D2B2F1F3-E3ED-43C6-9B24-2D32028E99B4%40gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CA

Re: [beagleboard] Best (most-stable) console image to start from?

[William Hermans]

My experiences has in the past been to stick with the Wheezy image, and
just upgrade the kernel to 4.1.x. Perhaps 4.4.x, but I'm still on the fence
with that one. Then . . .

remote_proc == *TI* kernel.
uio_pruss == *bone* kernel.

The rest is hit and / or miss trial by error.

Now, with all the above said. I am currently working with one of the later
Jessie images, and having backed out of systemd back into sysv for an init
daemon. My reason for Jessie is that I needed a newer gcc ( 4.7 + I think )
to compile the newer versions of Nodejs. I'm currently using. . .

william@beaglebone:~/dev$ node -v
v4.2.6
william@beaglebone:~/dev$ npm -v
3.9.0
william@beaglebone:~/dev$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

But anyway, I'm not 100% sure I'll use a Jessie image, but I'm trying to
making it work. Otherwise I'd have to fall all the way back to v0.10.x for
Nodejs, at which point I'd fall back to Wheezy as well. I still Have a lot
to test though, which I will not be able to completely test until I get a
good portion of the software written for using nearly all the pins on the
P8 / P9 headers . . . which will take a while as I have a lot I need to
research javascript / Nodejs wise. Plus we're usually pretty busy here
during the spring / summer. So "round-to-its" are fewer, and further in
between.



On Thu, May 19, 2016 at 11:46 AM, Super Twang  wrote:

>
> > On May 19, 2016, at 12:39 PM, William Hermans  wrote:
> > No one can make this determination for you. As there is no "one size
> fits all" image.
>
> @William
> I understand.  I’m not asking for that.  I’m already doing a fair bit of
> add and subtract, even starting from a console image, to come up with the
> best image for my own application.  I’m just looking for the gut-check of
> folks who understand the various images and kernels better than I, to know
> which ones might be the best starting point.  (ie those that have issues
> that might affect me, PRU/uio_pruss and others that I don’t know about).
>
> The process of trying all of the available console images, customizing
> them and subjecting all of them to long-term stability tests, is a
> painstaking, and long process that I am in the middle of.  I have already
> gleaned what I can from forums, etc.  I know I’m not the only one going
> through this process, so I’m just hoping that someone share a few tips to
> help me reduce the search space.  With no description of what each image
> contains, reference of what issues popped up for users of them, and no
> historical record of why new versions were rolled (presumably because some
> problems were fixed, and the newer one is better), I don’t have a lot to
> work with.  Maybe this stuff exists somewhere, and I just don’t know
> where?  If so, point me to it and I’ll keep reading.
>
> Here’s what I’m working with:
>
> “Use an official image” - adds a bunch of stuff that is inappropriate for
> an embedded device (graphical targets, node, cloud9, etc), I don’t know
> enough about what I can safe remove to start from here.
>
> “Use the barefs” - really quite appealing, and I may get there someday,
> but for now, I don’t have a non-virtualized-os linux dev machine.
>
> The best I’ve found so far:
>
> “Use a console image”
>
> Ok, so I’m using a console image:
>
> “Use the latest image” - exposes me to the potentially lurking issues of
> the cutting edge.  I am uncomfortable with that solution because the level
> of risk is too high for me.
>
> My own reasoning is “Choose a long-term-support variant" (so it will have
> the chance to settle into greater stability).
>
> BUT, I’ve been having a hard time solving stability problems with:
> Jessie 8.4 console image of 4/7/2016
> Kernel:  4.4.9 -bone-rt-r10 kernel
>
> and know there was a period of uio_pruss issues somewhere in 3.8 - 4.1.
> So, my thought was to back up to Wheezy.  But, which console image should I
> start with???  Was the latest one the best?
>
> I’m thankful for any input, even if it is to tell me I’m going about this
> the wrong way.  That said, one person telling me I’m doing it wrong is
> probably not going to help, unless they can point me to a better way.  If
> not, then I’ll keep learning as best as I can, and asking for help when I’m
> stuck.
>
> Best,
> ST
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/70D48203-53CF-4CF1-A901-700DA631B6A1%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For mo

Re: [beagleboard] TPS65217 & Vdd_core 1.125V or 1.2V or 1.1V or .... ?

[John Syne]

http://processors.wiki.ti.com/index.php/DVFS_User_Guide

Regards,
John




> On May 19, 2016, at 12:46 AM, Micka  wrote:
> 
> I already looked at that file and in the starterware there is no line that 
> contain DEFDCD3.
> 
> What I'm saying, is that nowhere I find the same value for DEFDCD3. Some time 
> it's 1.125V, somehwere else it's .95V-1.1V and in the BB_SRM it is 1.1V .
> 
> I'm asking to Gerald, what is the correct value for Vdd_Core ? I think that 
> the correct one is 1.1V. And what is the range ? 0.95V-1.1V ( device tree )
> 
> Le mer. 18 mai 2016 à 22:31, John Syne  > a écrit :
>> On May 18, 2016, at 1:58 AM, Micka > > wrote:
>> 
>> Hi,
>> 
>> In the u-boot 
>> http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;h=4330be64994dc6cbfaff4b865fee44d82f660a3d;hb=HEAD#l255
>>  
>> 
>> 
>> there is those lines :
>> 
>>  255 
>> 
>>  /* Set DCDC3 (CORE) voltage to 1.125V */
>>  256 
>> 
>>  if (tps65217_voltage_update(TPS65217_DEFDCDC3,
>>  257 
>> 
>>  TPS65217_DCDC_VOLT_SEL_1125MV))
>> 
>> 
>> In the device tree there is those lines :
>> 
>>  dcdc3_reg: regulator@2 {
>>  /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% 
>> tolerance */
>>  regulator-name = "vdd_core";
>>  regulator-min-microvolt = <925000>;
>>  regulator-max-microvolt = <115>;
>>  regulator-boot-on;
>>  regulator-always-on;
>>  };
>> 
>> in the starterware from texas + the patch for the bbb I have nothing 
>> concerning the DEFDCD3. 
>> 
>> And finally in the BBB_SRM you have those lines :
>> 
>> The VDD_CORE rail can deliver up to 1.2A at 1.1V. This rail is not 
>> accessible for use anywhere else on the board and only connects to the 
>> processor. This rail is fixed at 1.1V and is not scaled.  
>> 
>> So what is the correct configuration for this output ?
> 
> I believe this is done in bootloader/src/armv7a/am335x/bl_platform.c
> 
> In essence, you have to create a bootable SDCard for Starterware which sets 
> the regulator voltages for you. 
> 
> Regards,
> John
>> 
>> 
>> Micka,
>> 
>> 
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> 
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtm7heTJ45tuWoHt9v1ajBV4XN%2BCk7t%2BfGTn-mrjjJsD%2BA%40mail.gmail.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/D2B2F1F3-E3ED-43C6-9B24-2D32028E99B4%40gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtk%3DekMzxdLE6J%2BnUF6aef7EC78EUg_GPRzA76_yAPk%3DiQ%40mail.gmail.com
>  
> 

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

Certainly there wil be use cases for all. But one thing you need to be
aware of with recharge cycles on batteries. Is that a recharge cycle is
only counted when the battery voltage falls below a certain percentage. I
believe this percentage is difference for every chemistry type. But I can
say that for lead acid batteries, the recharge cycle is two fold.

First of the battery discharge goes below 75% this is a normal recharge
cycle.
Second, if the battery goes below 60% discharge is is akin to taking away
100 normal discharge depth cycles.

But again, other chemistries I know are going to be different as some stay
fairly steady in voltage throughout their whole discharge cycle.

On Thu, May 19, 2016 at 11:06 AM, zamek42  wrote:

> Hi All,
>
> On 05/19/2016 05:33 PM, Super Twang wrote:
>
>> @Lachlan
>> Thanks for the info Lachlan.
>>
>> Re: Supercap reliability…
>> My basic understanding is that if you design with supercaps for a
>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>> pretty obtainable operating conditions they effectively last forever.
>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>> “effectively”) in the prior assertion, but...
>>
>> My particular use case — indoor temps but in a wall, 5v power — might see
>> a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re talking
>> about would have to be a pretty harsh/industrial environment, no?
>>
>> Does anyone (who has done it, or knows how) have a sense of how
>> straightforward it is to achieve a supercap-based system design that keeps
>> the components in a range that’d keep them healthy for “Effectively
>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>> Or, do the requirements we’re looking at for a basic, indoor, power system
>> really push the supercaps into the “Quickly-used-up” zone?
>>
> Yes we have some experience about supercaps.
>
> We have an organ controller which is working two years ago, approximately
> 3-4 on/off  per day. Yes it is an indoor application.
> Our second application is an industrial environment with Pandaboard which
> is working since last september approximately 1 on/off per day. It is a
> semi indoor environment.
> Our third application is a timelapse camera system with Raspberry (
> http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early of
> march. It is an outdoor application which is working 7/24.
>
> In other point of view, if you checked the parameters of supercap for
> example
> http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922
> you can see:
>
> operating temperature: -40-+60C
> Life cycles: 50
>
> A simple NiCd accumulator is much more weight, and its lifecycle is much
> more less, the operating temperature is 0-45C and lifecycle is less than
> 1.
>
> So supercap seems to be  ideal for power supply to an embedded system, but
> it needs a little bit complicated controller electronic.
> best regards,
>
>
> --
> Zoltan (Zamek) Zidarics
> programmer
> email:zame...@gmail.com
> Self Playing Pipe Organ Systems
> http://replayorgan.eu
>
> --
> For more options, visit http://beagleboard.org/discuss
> --- You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqq6BJwaSB8AGeZbbx%3D5ehiowL_nhLSQPVQ7XBQDasGKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

Oh, right, heh, so the main point I had for the above was that if you never
discharge a battery below 90%, then cycles are very likely not counted.
Which is another problem in of its self. Batteries do need to be
"exercised".

Another thing I was considering just now is that these Lithium iron
phosphate batteries are indead pretty cool. However, they would require
external circuitry to use with this board. Which is not necessarily a bad
thing, but if you're looking to keep costs at a minimum. Then they are not
the most ideal solution.

On Thu, May 19, 2016 at 12:17 PM, William Hermans  wrote:

> Certainly there wil be use cases for all. But one thing you need to be
> aware of with recharge cycles on batteries. Is that a recharge cycle is
> only counted when the battery voltage falls below a certain percentage. I
> believe this percentage is difference for every chemistry type. But I can
> say that for lead acid batteries, the recharge cycle is two fold.
>
> First of the battery discharge goes below 75% this is a normal recharge
> cycle.
> Second, if the battery goes below 60% discharge is is akin to taking away
> 100 normal discharge depth cycles.
>
> But again, other chemistries I know are going to be different as some stay
> fairly steady in voltage throughout their whole discharge cycle.
>
> On Thu, May 19, 2016 at 11:06 AM, zamek42  wrote:
>
>> Hi All,
>>
>> On 05/19/2016 05:33 PM, Super Twang wrote:
>>
>>> @Lachlan
>>> Thanks for the info Lachlan.
>>>
>>> Re: Supercap reliability…
>>> My basic understanding is that if you design with supercaps for a
>>> “Everyday” (ie not too hardcore) indoor use case, and keep them within some
>>> pretty obtainable operating conditions they effectively last forever.
>>> Obviously there’s some ambiguity (“everyday” “pretty obtainable”,
>>> “effectively”) in the prior assertion, but...
>>>
>>> My particular use case — indoor temps but in a wall, 5v power — might
>>> see a temp range of 15° - 35°C max I’d guess.  The 70°C - 105°C you’re
>>> talking about would have to be a pretty harsh/industrial environment, no?
>>>
>>> Does anyone (who has done it, or knows how) have a sense of how
>>> straightforward it is to achieve a supercap-based system design that keeps
>>> the components in a range that’d keep them healthy for “Effectively
>>> forever?”  ie 20k+ cycles? (better than bats) 100k+? (effectively forever)
>>> Or, do the requirements we’re looking at for a basic, indoor, power system
>>> really push the supercaps into the “Quickly-used-up” zone?
>>>
>> Yes we have some experience about supercaps.
>>
>> We have an organ controller which is working two years ago, approximately
>> 3-4 on/off  per day. Yes it is an indoor application.
>> Our second application is an industrial environment with Pandaboard which
>> is working since last september approximately 1 on/off per day. It is a
>> semi indoor environment.
>> Our third application is a timelapse camera system with Raspberry (
>> http://1nap1perc.hu/pecsi-magashaz-bontas/ ) which is started at early
>> of march. It is an outdoor application which is working 7/24.
>>
>> In other point of view, if you checked the parameters of supercap for
>> example
>> http://www.newark.com/illinois-capacitor/506dcn2r7q/super-capacitor-aluminum-elect/dp/90R9922
>> you can see:
>>
>> operating temperature: -40-+60C
>> Life cycles: 50
>>
>> A simple NiCd accumulator is much more weight, and its lifecycle is much
>> more less, the operating temperature is 0-45C and lifecycle is less than
>> 1.
>>
>> So supercap seems to be  ideal for power supply to an embedded system,
>> but it needs a little bit complicated controller electronic.
>> best regards,
>>
>>
>> --
>> Zoltan (Zamek) Zidarics
>> programmer
>> email:zame...@gmail.com
>> Self Playing Pipe Organ Systems
>> http://replayorgan.eu
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> --- You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/36c43943-2e37-e473-1524-398120205a19%40gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpxj0U7XkJVPDeZeBVhsBzQX%2BPVAnkKwgfoUoFTLMfnCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Best (most-stable) console image to start from?

[Wally Bkg]

I'm not ready yet, other things need to be finished first, but unless 
better recommendations and examples appear before I get to it, I plan on 
starting with the 3.8.13-bone70 kernel and Wheezy (7.8) used by Derek 
Malloy in his "Exploring Beaglebone"  PRU examples;
http://exploringbeaglebone.com/chapter13/#prettyPhoto

I think its pretty easy to do worse  :)


On Thursday, May 19, 2016 at 11:50:00 AM UTC-5, Super Twang wrote:
>
>
> Can anyone recommend the most stable version of RCN's console images on 
> which to base an embedded device that uses the PRU (uio_pruss)?
>
> From what I understand there was incompatibility with the PRU somewhere 
> between 3.8 - 4.1.
>
> I'd like to go back in time (probably to a Wheezy install) to a point of 
> known good stability (ie no reboots caused by OS/hardware), but I'm not 
> sure where to land.
>
> I most recently tried:
>
> Jessie 8.4 console image of 4/7/2016
> Kernel:  4.4.9 -bone-rt-r10 kernel
>
> but am seeing spontaneous reboots (even not running my own SW).  
>
> Thanks for any guidance you can provide!
>
> Best,
> ST
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/05f75c68-b4ed-4e90-8012-0ac94dd9d17a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[John Syne]

https://en.wikipedia.org/wiki/Supercapacitor 


If you operate the supercap at lower than max voltage and keep the temperature 
at close to 25C, the supercap will last as much as 20 years. No battery comes 
even close. You also need to look at lifecycle cost, not just cost of 
components. If you have to switch out the battery every few years, then the 
lifecycle cost for a battery will be much higher than supercaps. 

Regards,
John




> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
> 
> Have a look at https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery 
> 
> Depending on current/temperature  they have much better life,  up to 10,000 
> cycles 
> and much better fire safety than LiPo,  you may even be able to ship then on 
> flights.
> 
> Supper caps,  don't have a good life time,  in fact they much worse then 
> Aluminum Capacitors 
> 
> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much more 
> life at 25C
> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost $2  
> in 5k
> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs @ 
> 70°C and cost $6.000 in 5k 
> (Digikey prices)
> So to get the Max life,  use the step up switching reg to say 40V  (remember 
> that energy on capt is = 1/2CV^2 )
> so double the voltage is 4 times the energy)  then user a switch to step down 
> to you required voltage/current
> So for max and life,  only switch to the backup Caps when power fail's, that 
> way they remain cool,
> give max life,  and will give you  good hold times.  And of course all under 
> mic-controller control.
> per my example circuit.. (example dose not have the control circuit, but can 
> be easily added )
> 
> Lachlan
> 
> 
> 
> 
> 
> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  > wrote:
> 
> > You can sum it all up into this; The problem is completely solved by using 
> > a battery and having acpid installed. Except you need a way to completely 
> > disconnect power, from the BBB's input, for a single, or perhaps two corner 
> > cases that would otherwise require a hard reset.
> 
> I love the no-nonsense mentality, and quality design behind this approach for 
> most use cases.  But, for some high-reliability use cases like mine -- a 
> device permanently installed in a remote, client wall — batteries aren’t a 
> great fit.
> 
> For long-term accessibility:Battery maintenance, even after years 
> of initial functionality, is extremely inconvenient or impossible.
> For insurance reasons:  The potential liability of installing 
> LiPo, which is known to have potential fire issues, into a client’s wall.
> For shipping reasons:   The added hassle of international 
> shipping of LiPo-based systems.
> 
> > All these fancy high cost solutions are honestly ridiculous, and if you can 
> > just use an OTS UPS . . .
> 
>  Hardware cost is relative.  The “high” cost (<$100) of a system 
> design is nothing, if it will potentially save me things like panicked client 
> calls, last-minute international plane tickets and high-pressure field 
> repairs.  Those just aren’t fun.  Obviously every project out there isn’t 
> heading to a NASA rover, but in some lines of work this kind of service is 
> expected when a high-end, mission-critical system goes down.  In the end, if 
> I do my job right, the price is just passed on to the client who is willing 
> to pay a premium for a high reliability, maintenance-free product.
> 
> I’d like to be able to deploy those systems based on the BBB, because I know 
> it, find the platform highly versatile, and a good match for the variety of 
> projects I take on.  I think the PRUs especially make this a very unique 
> little SoC.
> 
> Best,
> ST
> 
> 
> 
> --
> For more options, visit http://beagleboard.org/discuss 
> 
> ---
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving e

Re: [beagleboard] Re: Best (most-stable) console image to start from?

[William Hermans]

Hi Wally,

No really an argument per se, but just an observation on my own behalf. I
have no found anything to be broken in terms of functionality on the latest
4.1.x kernels. One difference that I did notice right away however is that
the 4.1.x kernels are more responsive, while using the operating system.

The uio_pruss examples all work fine, or at least worked fine with 4.1.x
when i tested a couple months ago, or slightly longer.

On Thu, May 19, 2016 at 12:23 PM, Wally Bkg  wrote:

> I'm not ready yet, other things need to be finished first, but unless
> better recommendations and examples appear before I get to it, I plan on
> starting with the 3.8.13-bone70 kernel and Wheezy (7.8) used by Derek
> Malloy in his "Exploring Beaglebone"  PRU examples;
> http://exploringbeaglebone.com/chapter13/#prettyPhoto
>
> I think its pretty easy to do worse  :)
>
>
> On Thursday, May 19, 2016 at 11:50:00 AM UTC-5, Super Twang wrote:
>>
>>
>> Can anyone recommend the most stable version of RCN's console images on
>> which to base an embedded device that uses the PRU (uio_pruss)?
>>
>> From what I understand there was incompatibility with the PRU somewhere
>> between 3.8 - 4.1.
>>
>> I'd like to go back in time (probably to a Wheezy install) to a point of
>> known good stability (ie no reboots caused by OS/hardware), but I'm not
>> sure where to land.
>>
>> I most recently tried:
>>
>> Jessie 8.4 console image of 4/7/2016
>> Kernel:  4.4.9 -bone-rt-r10 kernel
>>
>> but am seeing spontaneous reboots (even not running my own SW).
>>
>> Thanks for any guidance you can provide!
>>
>> Best,
>> ST
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/05f75c68-b4ed-4e90-8012-0ac94dd9d17a%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoLU_XWra2aw13GWqmaAujHUt238X%3D0gJcqoa5bQdSn5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] spontaneous reboot issues bbb, jessie 8.4 console image of 4/7/2016, 4.4.9 -bone-rt-r10 LTS kernel

[Wally Bkg]

I've a BBW running 24/7 since December with: BeagleBoard.org Debian Image 
2015-11-12, kernel 4.1.18-ti-r49 #1 SMP PREEMPT Fri Feb 26 00:12:54 UTC 
2016 armv7l GNU/Linux

It is on a UPS and I've had exactly one lock up, happened last week -- 
actually looked like it had powered down, all LEDs off.  We also had a 
thunderstorm roll through about when its last heartbeat message came, but 
the UPS never "beeped" nor did the lights flicker (unusual, this generally 
means it was only a very minor thunderstorm as things go around here).

I posted a thread on it when it happened.  What was weird was the reset 
button or unplugging and re-plugging the 5V "barrel 
connector" power-supply didn't restart it, so I thought it'd fried.  I left 
it unplugged while checking some other parts of the system and when I when 
back to it 10+ minutes later it booted right up when I plugged it in -- 
almost like some kind of thermal overload, but nothing is even warm to the 
touch on the board.  It still running 24/7 since, another 
small thunderstorm is rolling through as I type this, I'll see what if 
anything happens.



On Thursday, May 19, 2016 at 12:08:17 PM UTC-5, Super Twang wrote:
>
>
> Robert,
>
> You make a good point.  Maybe a brownout/blackout caused it.  We had a 
> tstorm roll through here last night, and I’m not running power from a UPS, 
>   I wish there was someway to catch a spontaneous power loss in the logs so 
> I could differentiate that out, but the syslog shows nothing in these 
> cases.  I’ll try again with (more) stable power.
>
> Is it normal for the buffer count to steadily increase like I’m seeing? 
>  Could it be my own stat logging that is causing it?  Maybe I’m doing 
> something and just not seeing it straight, but I’m trying to have as 
> minimal an impact as I can on the running system.
>
> Thanks for your thoughts.
>
> Best,
> ST
>
> PS. Out of curiosity, how many machines are in your testing farm?  Do you 
> have a photo?  I’ve got a whopping 2. :)
>
>
> On May 19, 2016, at 11:37 AM, Robert Nelson  > wrote:
>
> That's odd...
>
> http://rcn-ee.homeip.net:81/farm/uptime/test-bbb-6.log
>
> Double check your power supply.. 
>
> On May 19, 2016 11:34 AM, "Super Twang" > 
> wrote:
> >
> >
> > PS. Is this the best place to put bug/issue reports?  I believe this 
> relates to the core image & kernel of a Jessie LTS release.
> >
> > ---
> >
> > I'm seeing semi-regular spontaneous reboots on the BBB.  Here's what I'm 
> seeing:
> >
> > Running 'top', the "Mem Buffers" field, (4th line, far right), is 
> steadily increasing until the system reboots at around (41180 buffers).
> >
> > Anyhow, since I'm going after max stability, this is of concern to me, 
> so I've been doing a little testing.
> >
> > I'm not entirely sure what I'm looking for, but since I'm not running 
> any of my own apps in this setup, I'm hoping the results might be useful 
> for someone else?
> >
> >
> > I have logs available from
> >
> > vmstat -s K -n 1 >> logfile
> >
> > as well as a screengrab at time of fail of 
> >
> > 'top'
> >
> > and
> >
> > 'slabtop'
> >
> > Let me know if you have any insights or would like the logs.  I still 
> have the image and am happy to run other tests if it'll help.  
> > In the meantime, I'm going to revert to a Wheezy console image and hope 
> to find more stability there.
> >
> > Best,
> > Dave
> >
> > - setup is below
> >
> > Setup:
> >
> > Running from image:  RCN's jessie 8.4 console image of 4/7/2016  (with 
> some packages removed, and a developer environment installed)
> >
> > Kernel:  4.4.9 -bone-rt-r10 kernel
> >
> > Running from SDCard
> >
> > ssh'ed in via DCHP connected ethernet, most recently capturing vmstat to 
> a log file.
> >
> >
> >
> > PS.  Under a different testing scenario where I am running my own http 
> server/app, I see strange behavior too.  I can say that my app has been 
> extensively tested for leaks, etc, BUT can't rule out that it is my own app 
> causing the issues when I am running it.   Nonetheless, maybe the 
> strangeness will help dignose the above issue, so I'm including it here.
> >
> > The strangeness I'm seeing is this:  There is a 24 hour recurring 
> pattern to the reboots.In the log below, I'm the number to the right of 
> "Startup" is "seconds since last startup".
> >
> > Any idea what this might be???  Logfile rotation?  Some kind of cron-job 
> interference?
> >
> > 2016-05-17 07:36:14: Startup   1566731504* 
> >
> > 2016-05-17 11:57:11: Startup   15657** 
> >
> > 2016-05-17 14:21:10: Startup8639** 
> >
> > 2016-05-17 16:20:27: Startup7157** 
> >
> > 2016-05-17 17:22:41: Startup3734** 
> >
> > 2016-05-17 18:23:23: Startup3642** 
> >
> > 2016-05-17 19:24:06: Startup3643** 
> >
> > 2016-05-17 20:25:33: Startup3687** 
> >
> > 2016-05-17 21:26:16: Startup36

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

All design is a trade of, if you can control your environment that is the
best of all possible words,
no lighting strike's, no one using there cell phone's 2 cm away from you
board,  clean air,
no toxic chemical attacking your connector's to deal with.
And of course if you can afford the very best Mil speck parts, that's even
better.
But most designers are not in that boat, and need to do the max with the
lowest cost.
that where the hard work is.

Lachlan




On Thu, May 19, 2016 at 12:25 PM, John Syne  wrote:

> https://en.wikipedia.org/wiki/Supercapacitor
>
> If you operate the supercap at lower than max voltage and keep the
> temperature at close to 25C, the supercap will last as much as 20 years. No
> battery comes even close. You also need to look at lifecycle cost, not just
> cost of components. If you have to switch out the battery every few years,
> then the lifecycle cost for a battery will be much higher than supercaps.
>
> Regards,
> John
>
>
>
>
> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
>
> Have a look at
> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
> Depending on current/temperature  they have much better life,  up to
> 10,000 cycles
> and much better fire safety than LiPo,  you may even be able to ship then
> on flights.
>
> Supper caps,  don't have a good life time,  in fact they much worse then 
> Aluminum
> Capacitors
> 
> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
> more life at 25C
> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
> $2  in 5k
> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000 Hrs
> @ 70°C and cost $6.000 in 5k
> (Digikey prices)
> So to get the Max life,  use the step up switching reg to say 40V
> (remember that energy on capt is = 1/2CV^2 )
> so double the voltage is 4 times the energy)  then user a switch to step
> down to you required voltage/current
> So for max and life,  only switch to the backup Caps when power fail's,
> that way they remain cool,
> give max life,  and will give you  good hold times.  And of course all
> under mic-controller control.
> per my example circuit.. (example dose not have the control circuit, but
> can be easily added )
>
> Lachlan
>
>
>
>
> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:
>
>>
>> > You can sum it all up into this; The problem is completely solved by
>> using a battery and having acpid installed. Except you need a way to
>> completely disconnect power, from the BBB's input, for a single, or perhaps
>> two corner cases that would otherwise require a hard reset.
>>
>> I love the no-nonsense mentality, and quality design behind this approach
>> for most use cases.  But, for some high-reliability use cases like mine --
>> a device permanently installed in a remote, client wall — batteries aren’t
>> a great fit.
>>
>> For long-term accessibility:Battery maintenance, even after
>> years of initial functionality, is extremely inconvenient or impossible.
>> For insurance reasons:  The potential liability of
>> installing LiPo, which is known to have potential fire issues, into a
>> client’s wall.
>> For shipping reasons:   The added hassle of international
>> shipping of LiPo-based systems.
>>
>> > All these fancy high cost solutions are honestly ridiculous, and if you
>> can just use an OTS UPS . . .
>>
>>  Hardware cost is relative.  The “high” cost (<$100) of a system
>> design is nothing, if it will potentially save me things like panicked
>> client calls, last-minute international plane tickets and high-pressure
>> field repairs.  Those just aren’t fun.  Obviously every project out there
>> isn’t heading to a NASA rover, but in some lines of work this kind of
>> service is expected when a high-end, mission-critical system goes down.  In
>> the end, if I do my job right, the price is just passed on to the client
>> who is willing to pay a premium for a high reliability, maintenance-free
>> product.
>>
>> I’d like to be able to deploy those systems based on the BBB, because I
>> know it, find the platform highly versatile, and a good match for the
>> variety of projects I take on.  I think the PRUs especially make this a
>> very unique little SoC.
>>
>> Best,
>> ST
>>
>>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/8A4F134B-E937-4958-8A25-E8BEDB02E6FC%40lumieria.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message becaus

Re: [beagleboard] Hardware watchdog for BBB

[William Hermans]

>
>
>
>
>
>
>
>
> *All design is a trade of, if you can control your environment that is the
> best of all possible words,no lighting strike's, no one using there cell
> phone's 2 cm away from you board,  clean air,no toxic chemical attacking
> your connector's to deal with.And of course if you can afford the very best
> Mil speck parts, that's even better.But most designers are not in that
> boat, and need to do the max with the lowest cost.that where the hard work
> is.*
> *Lachlan*
>

Exactly. Plus many people would view having to replace a part every couple
years as a potential source of income - From service calls. I can say
though that for our own application. Where out boards would be deployed.
Power outages may not be impossible, but usually are dealt with
immediately. Also, backup generators are typically in place too. So a
single LiPO battery is just a low cost added bit of insurance.

On Thu, May 19, 2016 at 12:40 PM, Lachlan Audas  wrote:

> All design is a trade of, if you can control your environment that is the
> best of all possible words,
> no lighting strike's, no one using there cell phone's 2 cm away from you
> board,  clean air,
> no toxic chemical attacking your connector's to deal with.
> And of course if you can afford the very best Mil speck parts, that's even
> better.
> But most designers are not in that boat, and need to do the max with the
> lowest cost.
> that where the hard work is.
>
> Lachlan
>
>
>
>
> On Thu, May 19, 2016 at 12:25 PM, John Syne  wrote:
>
>> https://en.wikipedia.org/wiki/Supercapacitor
>>
>> If you operate the supercap at lower than max voltage and keep the
>> temperature at close to 25C, the supercap will last as much as 20 years. No
>> battery comes even close. You also need to look at lifecycle cost, not just
>> cost of components. If you have to switch out the battery every few years,
>> then the lifecycle cost for a battery will be much higher than supercaps.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On May 19, 2016, at 2:12 AM, Lachlan Audas  wrote:
>>
>> Have a look at
>> https://en.wikipedia.org/wiki/Lithium_iron_phosphate_battery
>> Depending on current/temperature  they have much better life,  up to
>> 10,000 cycles
>> and much better fire safety than LiPo,  you may even be able to ship then
>> on flights.
>>
>> Supper caps,  don't have a good life time,  in fact they much worse then 
>> Aluminum
>> Capacitors
>> 
>> example the LGU1H103MELB 100,000uF has a life 3000 Hrs @ 105°C  and much
>> more life at 25C
>> and it rated for -40C to +105C,   and 4.09 amps ripple ratting, and cost
>> $2  in 5k
>> where as the BZ015A104ZSB 100mF (100,000uF) supper cat  has only  1000
>> Hrs @ 70°C and cost $6.000 in 5k
>> (Digikey prices)
>> So to get the Max life,  use the step up switching reg to say 40V
>> (remember that energy on capt is = 1/2CV^2 )
>> so double the voltage is 4 times the energy)  then user a switch to step
>> down to you required voltage/current
>> So for max and life,  only switch to the backup Caps when power fail's,
>> that way they remain cool,
>> give max life,  and will give you  good hold times.  And of course all
>> under mic-controller control.
>> per my example circuit.. (example dose not have the control circuit, but
>> can be easily added )
>>
>> Lachlan
>>
>>
>>
>>
>> On Mon, May 16, 2016 at 4:52 PM, Dave Loomis  wrote:
>>
>>>
>>> > You can sum it all up into this; The problem is completely solved by
>>> using a battery and having acpid installed. Except you need a way to
>>> completely disconnect power, from the BBB's input, for a single, or perhaps
>>> two corner cases that would otherwise require a hard reset.
>>>
>>> I love the no-nonsense mentality, and quality design behind this
>>> approach for most use cases.  But, for some high-reliability use cases like
>>> mine -- a device permanently installed in a remote, client wall — batteries
>>> aren’t a great fit.
>>>
>>> For long-term accessibility:Battery maintenance, even after
>>> years of initial functionality, is extremely inconvenient or impossible.
>>> For insurance reasons:  The potential liability of
>>> installing LiPo, which is known to have potential fire issues, into a
>>> client’s wall.
>>> For shipping reasons:   The added hassle of
>>> international shipping of LiPo-based systems.
>>>
>>> > All these fancy high cost solutions are honestly ridiculous, and if
>>> you can just use an OTS UPS . . .
>>>
>>>  Hardware cost is relative.  The “high” cost (<$100) of a system
>>> design is nothing, if it will potentially save me things like panicked
>>> client calls, last-minute international plane tickets and high-pressure
>>> field repairs.  Those just aren’t fun.  Obviously every project out there
>>> isn’t heading to a NASA rover, but in some lines of work this kind of
>>> service is expected when a high-end, mission-critical system goes dow

[beagleboard] How to Discern if a BBB is Dead

[cekins]

Hi,

I'm trying to learn how to use beaglebones for future projects. My job 
supplied my with 7 previously used ones (1 beaglebone black and 6 
beaglebone whites) in order to get started working on them. However when I 
tried to plug the bbb into a computer via micro USB cable only the power 
LED lit up and it only flashed a single time. The board also wasn't 
recognized by my computer (after having installed the drivers). I then 
tried with the other 6 beaglebone whites and they did the exact same thing 
as the black.

I have heard of these being very fragile when it comes to being powered and 
being shut down but I still can't think of anything that I did wrong. I 
also tried plugging them into a nearby desktop's USB ports and then an 
adafruit 5v power supply but they did they same thing each time.

What I need to know now is, are these boards all dead? Is there something 
from what I just described that would break these devices? And is there 
some sort of diagnostics that I can run to determine if they're still 
functioning?


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/28e1e298-3ac9-4d5a-a3ab-05ae08821f5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to Discern if a BBB is Dead

[Gerald Coley]

Well, at first thought, as you say, they were used. So, you may want to
talk to the previous owners. The flashing LED on the BBB typically
indicates an issue with some component on the board..

Gerald

On Thu, May 19, 2016 at 12:36 PM,  wrote:

> Hi,
>
> I'm trying to learn how to use beaglebones for future projects. My job
> supplied my with 7 previously used ones (1 beaglebone black and 6
> beaglebone whites) in order to get started working on them. However when I
> tried to plug the bbb into a computer via micro USB cable only the power
> LED lit up and it only flashed a single time. The board also wasn't
> recognized by my computer (after having installed the drivers). I then
> tried with the other 6 beaglebone whites and they did the exact same thing
> as the black.
>
> I have heard of these being very fragile when it comes to being powered
> and being shut down but I still can't think of anything that I did wrong. I
> also tried plugging them into a nearby desktop's USB ports and then an
> adafruit 5v power supply but they did they same thing each time.
>
> What I need to know now is, are these boards all dead? Is there something
> from what I just described that would break these devices? And is there
> some sort of diagnostics that I can run to determine if they're still
> functioning?
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/28e1e298-3ac9-4d5a-a3ab-05ae08821f5c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BeG7KC0fhFibpZqV9YeancAD0hnis%3D3MvYJy_Zh7BfcBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Best (most-stable) console image to start from?

[Super Twang]

@William
Thank you!  I really appreciate you sharing your approach.  Your clarification 
that the uio_pruss/remote_proc issue lies in the choice of kernel, not the 
version is a subtlety that was escaping me, despite having found my way to the 
bone-rt kernels.  I also hadn’t realized that a 4.1.x kernel was an option with 
a Wheezy image.  You just saved me days, if not weeks, of trial and error, and 
I really appreciate it.

> My experiences has in the past been to stick with the Wheezy image, and just 
> upgrade the kernel to 4.1.x. Perhaps 4.4.x, but I'm still on the fence with 
> that one. Then . . .
> remote_proc == *TI* kernel.
> uio_pruss == *bone* kernel.

@Wally
Thank you too for sharing as well.  Derek’s book is a great resource! 

Best,
ST

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5B4452E9-C99A-4DA3-A776-6B08A08A5A21%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: How to Discern if a BBB is Dead

[Wally Bkg]

Sorry if this is too obvious, but the BBW won't do anything without a micro 
SD card plugged in, do you have an SD card with a fresh image loaded and 
plugged it before powering up?

The BBB has an eMMC "flash" preloaded, so its likely dead if the previous 
owner didn't break the boot by messing with uEnv.txt or something else. 
 Still I'd try a fresh SD card on it too before giving up.

I've not found them to be particularly fragile with respect to just pulling 
the plug when things have frozen -- no keyboard/mouse response, no SSH 
login.  They are pretty fragile to probe slips when measuring the GPIO pins 
if things short to power or ground.

On Thursday, May 19, 2016 at 2:50:29 PM UTC-5, cek...@umich.edu wrote:
>
> Hi,
>
> I'm trying to learn how to use beaglebones for future projects. My job 
> supplied my with 7 previously used ones (1 beaglebone black and 6 
> beaglebone whites) in order to get started working on them. However when I 
> tried to plug the bbb into a computer via micro USB cable only the power 
> LED lit up and it only flashed a single time. The board also wasn't 
> recognized by my computer (after having installed the drivers). I then 
> tried with the other 6 beaglebone whites and they did the exact same thing 
> as the black.
>
> I have heard of these being very fragile when it comes to being powered 
> and being shut down but I still can't think of anything that I did wrong. I 
> also tried plugging them into a nearby desktop's USB ports and then an 
> adafruit 5v power supply but they did they same thing each time.
>
> What I need to know now is, are these boards all dead? Is there something 
> from what I just described that would break these devices? And is there 
> some sort of diagnostics that I can run to determine if they're still 
> functioning?
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a9d03368-4a3e-402c-9ea5-f0d11685ecc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP Quadrature detector

[Rick Mann]

> On May 19, 2016, at 10:04 , Wim Hellenthal  wrote:
> 
> I understand your question. But unfortunatly all New puchased boards carry a 
> version higher then bone47 that don't work either 

You should be able to install the bone47 kernel on those new boards without 
issue. It's a simple apt-get command:

sudo apt-get update
apt-cache search linux-image
sudo apt-get install  
sudo reboot



-- 
Rick Mann
rm...@latencyzero.com


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/30637994-E55E-481B-9E94-7FFDC4D06E8A%40latencyzero.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Best (most-stable) console image to start from?

[William Hermans]

Super Twang,

I think in terms of Jessie versus Wheezy though. You need to figure out how
new the software has to be for each version of Debian. Wheezy, will be very
reliable, but the software that it can run without too much work on your
behalf will be older. Not that Jessie wont be reliable either, but the
software it runs is newer, so perhaps not so tried and true.

Debian is not your typical Linux distribution however. Debian does not go
release with a version unless it has been rigorously tested. Which means,
perhaps there are still flaws, but  compared to other distro's they're
minor, and far rarer.

For me personally. The main reason why I still prefer Wheezy to Jessie is
familiarity. But I can attempt to make Jessie as familiar as possible for
me, and so far, it's worked out ok.

On Thu, May 19, 2016 at 1:03 PM, Super Twang  wrote:

> @William
> Thank you!  I really appreciate you sharing your approach.  Your
> clarification that the uio_pruss/remote_proc issue lies in the choice of
> kernel, not the version is a subtlety that was escaping me, despite having
> found my way to the bone-rt kernels.  I also hadn’t realized that a 4.1.x
> kernel was an option with a Wheezy image.  You just saved me days, if not
> weeks, of trial and error, and I really appreciate it.
>
> > My experiences has in the past been to stick with the Wheezy image, and
> just upgrade the kernel to 4.1.x. Perhaps 4.4.x, but I'm still on the fence
> with that one. Then . . .
> > remote_proc == *TI* kernel.
> > uio_pruss == *bone* kernel.
>
> @Wally
> Thank you too for sharing as well.  Derek’s book is a great resource!
>
> Best,
> ST
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5B4452E9-C99A-4DA3-A776-6B08A08A5A21%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORq9Ep09U-CycCrxAB2gwivuujJ5hOb0gSyADULHm4PjDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Best (most-stable) console image to start from?

[Wally Bkg]

Thanks this will be a real time saver for me too!  I'd prefer to stick with 
Jessie if possible, as it is the future.   

I permuted kernels on late Wheezy and early Jessie images (~7 months ago) 
trying to track down some USB webcam issues (two different HP models) on my 
BBB, no significant difference that I could see -- all had weird problems 
with repeated frame captures.  Ended up doing it with a Raspberry Pi2 
instead.  I haven't revisited the USB webcams with newer images as the Pi2 
is doing good enough for this.

On Thursday, May 19, 2016 at 2:28:43 PM UTC-5, William Hermans wrote:
>
> Hi Wally,
>
> No really an argument per se, but just an observation on my own behalf. I 
> have no found anything to be broken in terms of functionality on the latest 
> 4.1.x kernels. One difference that I did notice right away however is that 
> the 4.1.x kernels are more responsive, while using the operating system.
>
> The uio_pruss examples all work fine, or at least worked fine with 4.1.x 
> when i tested a couple months ago, or slightly longer.
>
> On Thu, May 19, 2016 at 12:23 PM, Wally Bkg  > wrote:
>
>> I'm not ready yet, other things need to be finished first, but unless 
>> better recommendations and examples appear before I get to it, I plan on 
>> starting with the 3.8.13-bone70 kernel and Wheezy (7.8) used by Derek 
>> Malloy in his "Exploring Beaglebone"  PRU examples;
>> http://exploringbeaglebone.com/chapter13/#prettyPhoto
>>
>> I think its pretty easy to do worse  :)
>>
>>
>> On Thursday, May 19, 2016 at 11:50:00 AM UTC-5, Super Twang wrote:
>>>
>>>
>>> Can anyone recommend the most stable version of RCN's console images on 
>>> which to base an embedded device that uses the PRU (uio_pruss)?
>>>
>>> From what I understand there was incompatibility with the PRU somewhere 
>>> between 3.8 - 4.1.
>>>
>>> I'd like to go back in time (probably to a Wheezy install) to a point of 
>>> known good stability (ie no reboots caused by OS/hardware), but I'm not 
>>> sure where to land.
>>>
>>> I most recently tried:
>>>
>>> Jessie 8.4 console image of 4/7/2016
>>> Kernel:  4.4.9 -bone-rt-r10 kernel
>>>
>>> but am seeing spontaneous reboots (even not running my own SW).  
>>>
>>> Thanks for any guidance you can provide!
>>>
>>> Best,
>>> ST
>>>
>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/05f75c68-b4ed-4e90-8012-0ac94dd9d17a%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/39aaca09-28cc-4b6c-959e-f10217635e2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Wally Bkg]

What kernel and image?

newer ones use config-pin to activate the UARTS and seem to have problems 
with some of the overlays.

On:  BeagleBoard.org Debian Image 2015-11-12 with kernel: 4.1.18-ti-r49 #1 
SMP PREEMPT Fri Feb 26 00:12:54 UTC 2016 armv7l GNU/Linux

It boots "cape-universal" and I enable UART1 wtih:
sudo config-pin P9.24 uart
sudo config-pin P9.26 uart

Before going too far, jumper RX to TX and test it with minicom, the default 
echo on will double type any keys you press in the console, and with echo 
off you get no response without the jumper and get the character with it 
installed.



On Thursday, May 19, 2016 at 10:26:44 AM UTC-5, Shaurabh Kumar Singh wrote:
>
> Yes i have already tried activating the serial ports as shown in the link 
> before. Still it did not seem to work.
>
> On Wednesday, May 18, 2016 at 4:46:20 PM UTC-4, Shaurabh Kumar Singh wrote:
>>
>> I have been trying to communicate with a CNC machine through RS 232 to 
>> the Beaglebone Black. 
>> Following are the Serial Port settings at the Machine
>> Baudrate=9600
>> Databits=8
>> Stopbits=1
>> Parity=None
>> CR only
>>
>> When i tried connecting it to my desktop(windows 10-using python) 
>> directly(done without using BBB) and i set the same parameters i got the 
>> response from the machine like i had expected.
>>
>> Although, when done using the BBB (debian), also using python, i just 
>> received the string command i sent to the machine. Following is the python 
>> code.
>>
>> import Adafruit_BBIO.UART as UART
>>
>> import serial, string
>>
>> UART.setup("UART1")
>> with serial.Serial(port="/dev/ttyO0",baudrate=9600,timeout=2) as ser: #i 
>> also tried mentioning databits and stopbits and other parameters but they 
>> still did not work
>> ser.write(b"Q100\r")
>> c=ser.readline().decode("utf-8","ignore")
>> print(c)
>> ser.close()
>>
>> This works all fine in windows(gives the serial no. as the output) but 
>> simply gives back Q100as output (same as input).
>>
>> I was wondering if it could be due to the different OS on my laptop and 
>> BBB. Should i try installing windows ce on the BBB and work with that?
>>
>>
>> Thank you
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1d7a4fe9-bed4-4000-a62b-817c3375a0a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Flashin BBB with new image I built from RC guide

[Matt Maher Peterson]

Hi again,

Trying to flash another device with the uSD that worked great before and 
gettting a bunch of odd stuff out the serial debugger port, ending in cylon 
LEDS :/

c: deleted inode referenced: 6031
dules/rusha/rusha.js") failed: Input/output error (5)
rsync: re[  176.707788] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: 
inode #3485: comm rsync: deleted inode referenced: 6040
adlink_stat("/opt/cloud9/build/s[  176.722007] EXT4-fs error (device 
mmcblk1p2): ext4_lookup:1416: inode #3485: comm rsync: deleted inode 
referenced: 6039
tandalonebuild/node_modules/rusha/rusha.sweet.js[  176.737121] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3486: comm rsync: 
deleted inode referenced: 6043
") failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/Gruntfile.js")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/LICENSE") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/rusha.js.map")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/send/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/send/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/simplefunc/test") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/simplefunc/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/source-map/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/source-map/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/systemd/example") 
failed: Input/output error (5)
[  182.934944] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6057
rsync: readlink_stat("/opt/cloud9/build/standalo[  182.951614] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6051
nebuild/plugins/c9.ide.closeconfirmation") failed: Input/output [  
182.969373] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6046
error (5)
rsync: readlink_stat("/opt/cloud9/bui[  182.985178] EXT4-fs error (device 
mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: deleted inode 
referenced: 6047
ld/standalonebuild/plugins/c9.ide.ace.keymaps") failed: Input/output error 
(5)
[  183.003398] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6058
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.connect.favic[  
183.021934] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6055
on") failed: Input/output error (5)
rsync: readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.core") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.collab") 
failed: Input/output error (5)
rsync: readlink_s[  183.057445] EXT4-fs error (device mmcblk1p2): 
ext4_lookup:1416: inode #3391: comm rsync: deleted inode referenced: 6060
tat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace") failed: 
Input/output error (5)
rsync: readlink_stat("/opt/cloud9/build/standalonebuild/plugins/[  
183.085578] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6050
c9.ide.dialog.wizard") failed: Input/output error (5)
rsync: re[  183.102634] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: 
inode #3391: comm rsync: deleted inode referenced: 6059
adlink_stat("/opt/cloud9/build/standalonebuild/p[  183.118903] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6052
lugins/c9.ide.ace.gotoline") failed: Input/outpu[  183.134504] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6053
t error (5)
rsync: readlink_stat("/opt/cloud9/build/standaloneb[  183.151302] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6048
uild/plugins/c9.ide.configuration") failed: Inpu[  183.168058] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6049
t/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace.repl") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace.statusbar") 
failed: Input/outpu[  183.199729] EXT4-fs error 

Re: [beagleboard] Flashin BBB with new image I built from RC guide

[Matt99eo]

Hi again,

Trying to flash another device with the uSD that worked great before and 
gettting a bunch of odd stuff out the serial debugger port, ending in cylon 
LEDS :/

c: deleted inode referenced: 6031
dules/rusha/rusha.js") failed: Input/output error (5)
rsync: re[  176.707788] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: 
inode #3485: comm rsync: deleted inode referenced: 6040
adlink_stat("/opt/cloud9/
build/s[  176.722007] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: 
inode #3485: comm rsync: deleted inode referenced: 6039
tandalonebuild/node_modules/rusha/rusha.sweet.js[  176.737121] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3486: comm rsync: 
deleted inode referenced: 6043
") failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/Gruntfile.js")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/LICENSE") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/rusha/rusha.js.map")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/send/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/send/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/simplefunc/test") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/simplefunc/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/source-map/node_modules")
 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/source-map/lib") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/node_modules/systemd/example") 
failed: Input/output error (5)
[  182.934944] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6057
rsync: readlink_stat("/opt/cloud9/build/standalo[  182.951614] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6051
nebuild/plugins/c9.ide.closeconfirmation") failed: Input/output [  
182.969373] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6046
error (5)
rsync: readlink_stat("/opt/cloud9/bui[  182.985178] EXT4-fs error (device 
mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: deleted inode 
referenced: 6047
ld/standalonebuild/plugins/c9.ide.ace.keymaps") failed: Input/output error 
(5)
[  183.003398] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6058
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.connect.favic[  
183.021934] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6055
on") failed: Input/output error (5)
rsync: readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.core") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.collab") 
failed: Input/output error (5)
rsync: readlink_s[  183.057445] EXT4-fs error (device mmcblk1p2): 
ext4_lookup:1416: inode #3391: comm rsync: deleted inode referenced: 6060
tat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace") failed: 
Input/output error (5)
rsync: readlink_stat("/opt/cloud9/build/standalonebuild/plugins/[  
183.085578] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: inode 
#3391: comm rsync: deleted inode referenced: 6050
c9.ide.dialog.wizard") failed: Input/output error (5)
rsync: re[  183.102634] EXT4-fs error (device mmcblk1p2): ext4_lookup:1416: 
inode #3391: comm rsync: deleted inode referenced: 6059
adlink_stat("/opt/cloud9/build/standalonebuild/p[  183.118903] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6052
lugins/c9.ide.ace.gotoline") failed: Input/outpu[  183.134504] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6053
t error (5)
rsync: readlink_stat("/opt/cloud9/build/standaloneb[  183.151302] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6048
uild/plugins/c9.ide.configuration") failed: Inpu[  183.168058] EXT4-fs 
error (device mmcblk1p2): ext4_lookup:1416: inode #3391: comm rsync: 
deleted inode referenced: 6049
t/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace.repl") 
failed: Input/output error (5)
rsync: 
readlink_stat("/opt/cloud9/build/standalonebuild/plugins/c9.ide.ace.statusbar") 
failed: Input/outpu[  183.199729] EXT4-fs error 

Re: [beagleboard] connman issues on latest Debian 8.4 release?

[Mike Erdahl]

Hi Robert,

Thanks a bunch!

I appreciate your quick response- sorry if this was posted somewhere 
already.  I did not know tethering would cause this, and probably never 
would have tried disabling it :)

Regards,
Mike

On Wednesday, May 18, 2016 at 7:52:18 PM UTC-5, RobertCNelson wrote:
>
> Hi Mike
>
> On Wed, May 18, 2016 at 7:08 PM, Mike Erdahl  > wrote:
>
>>
>> Accidentally posted this on the beaglebone google group... annoying.
>>
>> connman works just fine for my three different RTL81xx based USB WIFI 
>> adapters on the Debian Jessie 8.3 bb.org release, but wifi seems dead on 
>> the Debian Jessie 8.4 bb.org release (wifi scan either hangs, or does 
>> not find anything).  Same behavior on BeagleBone Black and Green, powered 
>> with external bricks.
>>
>> I run on both 8.3 and 8.4:
>>
>> $ sudo su
>> # connmanctl
>> connmanctl> enable wifi
>> connmanctl> scan wifi
>> connmanctl> services
>>
>> At this point, I either see my AP (Jessie 8.3), or nothing (Jessie 8.4)
>>
>> Checking 'technologies' on both releases does show WiFi is present, and 
>> powered.
>>
>> Is there any config magic required before using connman with Debian 8.4 
>> bb.org release?  Unfortunately I overwrote my SD card before capturing 
>> the kernel log, but it seemed like the rtl firmware was loading fine, with 
>> no errors being reported.
>>
>
> We have tether'ing enabled out of the box, so you need to disable that:
>
> $ sudo su
> # connmanctl
> connmanctl> tether wifi off
> connmanctl> enable wifi
> connmanctl> scan wifi
> connmanctl> services
>
> then it'll work just fine. ;)
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e2673e36-72bb-425a-815a-b09b269b39a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] connman issues on latest Debian 8.4 release?

[John Syne]

Hi Robert,

I would think that the need for tethering would be the exception so I’m not 
sure why you would set this on by default.

Regards,
John




> On May 18, 2016, at 5:51 PM, Robert Nelson  wrote:
> 
> Hi Mike
> 
> On Wed, May 18, 2016 at 7:08 PM, Mike Erdahl  > wrote:
> 
> Accidentally posted this on the beaglebone google group... annoying.
> 
> connman works just fine for my three different RTL81xx based USB WIFI 
> adapters on the Debian Jessie 8.3 bb.org  release, but wifi 
> seems dead on the Debian Jessie 8.4 bb.org  release (wifi 
> scan either hangs, or does not find anything).  Same behavior on BeagleBone 
> Black and Green, powered with external bricks.
> 
> I run on both 8.3 and 8.4:
> 
> $ sudo su
> # connmanctl
> connmanctl> enable wifi
> connmanctl> scan wifi
> connmanctl> services
> 
> At this point, I either see my AP (Jessie 8.3), or nothing (Jessie 8.4)
> 
> Checking 'technologies' on both releases does show WiFi is present, and 
> powered.
> 
> Is there any config magic required before using connman with Debian 8.4 
> bb.org  release?  Unfortunately I overwrote my SD card before 
> capturing the kernel log, but it seemed like the rtl firmware was loading 
> fine, with no errors being reported.
> 
> We have tether'ing enabled out of the box, so you need to disable that:
> 
> $ sudo su
> # connmanctl
> connmanctl> tether wifi off
> connmanctl> enable wifi
> connmanctl> scan wifi
> connmanctl> services
> 
> then it'll work just fine. ;)
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/ 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfNVZ67hGbBurH19Y41kvmwXtsizx8R74Fg44iVDJoSg%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CC8F84F9-71CF-42C2-8232-97B113571FDD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Shaurabh Kumar Singh]

BeagleBoard.org BeagleBone Debian Image 2014-04-23
Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l 
GNU/Linux

I am fairly new to beaglebone, could you tel me how to configure the 
cape-universal overlay.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/29dfca22-f47b-4cb9-a4e6-9a16627c15ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Shaurabh Kumar Singh]

I did try to configure it using "config-pin overlay cape-universal" but it
said
Loading cape-universal overlay
bash: line 0: echo: write error: File exists
Error loading device tree overlay file: cape-universal

What do i do

On Thu, May 19, 2016 at 6:41 PM, Shaurabh Kumar Singh 
wrote:

> BeagleBoard.org BeagleBone Debian Image 2014-04-23
> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l
> GNU/Linux
>
> I am fairly new to beaglebone, could you tel me how to configure the
> cape-universal overlay.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAEh-rEEu3SU%2Bt0o3GK24R71UAhp8j07TYHg6sFa1xRtHGXOs8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Shaurabh Kumar Singh]

I did try to configure it using "config-pin overlay cape-universal" but it 
said
Loading cape-universal overlay
bash: line 0: echo: write error: File exists
Error loading device tree overlay file: cape-universal

What do i do

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7d3ab9ca-1852-4295-8d34-4915e95514aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Serial Communication on Beaglebone Black

[Wally Bkg]

I'm not big on Python, but it looks like you are using some of the Adafruit 
libraries,  they are broken for some kernels, I'm not the guy to tell you 
if your current kernel is one of them.

To isolate the problem, do:
apt-get install minicom and jumper RX to TX.  

I think by default in Debian images you need to run minicom as root.   
>From my command history when I was playing with uart1:
sudo minicom -D /dev/ttyS1

OTOH your python script may also need to run as root with the default 
device permissions.

If minicom works (after you've jumpered TX to RX) you know the overlay is 
loading correctly, and the problem is either the Python library or the 
permissions your scripts runs with.

If minicom doesn't work the overlay is not loading correctly.  There has 
been a fair number of threads about what uart overlays to use with various 
kernels try some searching.

Hope this helps.


On Thursday, May 19, 2016 at 5:41:53 PM UTC-5, Shaurabh Kumar Singh wrote:
>
> BeagleBoard.org BeagleBone Debian Image 2014-04-23
> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l 
> GNU/Linux
>
> I am fairly new to beaglebone, could you tel me how to configure the 
> cape-universal overlay.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3e26cffd-df67-4867-8775-7e3716ea1af0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Installing Android on BeagleBone Green

[cpe . 3bdalla]

Hello all, 


I downloaded the android image from here 
 and I followed the usual instructions 
using Win32DiskImager. I inserted the 16GB SD card to the beaglebone and 
while holding down the S2 button that is next to the SD card slot I applied 
power using an external power supply. I kept the button pressed for few 
seconds after power is on.


Booting the on-board eMMC image will work fine, the beaglebone appears on 
my network with SSH port available. With this android image the board won't 
show up on the network; Port scanning sees the device but no open ports 
available, also ping sometimes gives me Time out or unreachable. I'm not 
sure if it even booted or not. The user LEDs are flashing probably 
according to there usual pattern.


I tried this  article but I get the 
same effect. As far as I know, the BB green and black are the same exact 
hardware which means the same should work on both, that's what BB website 
 is providing.


What am I missing here? Thank you in advance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/e6d24212-1606-4611-abb5-15a78710203a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Serial Communication on Beaglebone Black

[Shaurabh Kumar Singh]

Okay. I shall look it up.
By the way, i did confirm the working of the UART pins(UART1 RX to UART4 TX
and vice versa).
I had two terminal tabs open and when i typed into one and entered(UART1
settings) it showed up on the other terminal with UART4 settings. I
inferred that the Adafruit libraries work just fine for the BBB (correct me
if i am mistaken)

It is just that while interacting with a CNC machine(with a HAAS OS) it is
not communicating rather just showing up what is being sent.

On Thu, May 19, 2016 at 7:35 PM, Wally Bkg  wrote:

> I'm not big on Python, but it looks like you are using some of the
> Adafruit libraries,  they are broken for some kernels, I'm not the guy to
> tell you if your current kernel is one of them.
>
> To isolate the problem, do:
> apt-get install minicom and jumper RX to TX.
>
> I think by default in Debian images you need to run minicom as root.
> From my command history when I was playing with uart1:
> sudo minicom -D /dev/ttyS1
>
> OTOH your python script may also need to run as root with the default
> device permissions.
>
> If minicom works (after you've jumpered TX to RX) you know the overlay is
> loading correctly, and the problem is either the Python library or the
> permissions your scripts runs with.
>
> If minicom doesn't work the overlay is not loading correctly.  There has
> been a fair number of threads about what uart overlays to use with various
> kernels try some searching.
>
> Hope this helps.
>
>
> On Thursday, May 19, 2016 at 5:41:53 PM UTC-5, Shaurabh Kumar Singh wrote:
>>
>> BeagleBoard.org BeagleBone Debian Image 2014-04-23
>> Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l
>> GNU/Linux
>>
>> I am fairly new to beaglebone, could you tel me how to configure the
>> cape-universal overlay.
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/Z1s_NwXYNrw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3e26cffd-df67-4867-8775-7e3716ea1af0%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAEh-rEHrU%2B4oCZvN44Hcdzs44VPU4CWhkSpwPPrCiukPXTPG8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Installing Android on BeagleBone Green

[evilwulfie]

green does not have a hdmi framer. maybe the image expects a framer ?

On 5/19/2016 3:02 PM, cpe.3bda...@gmail.com wrote:
>
> Hello all, 
>
>
> I downloaded the android image from here
>  and I followed the usual
> instructions using Win32DiskImager. I inserted the 16GB SD card to the
> beaglebone and while holding down the S2 button that is next to the SD
> card slot I applied power using an external power supply. I kept the
> button pressed for few seconds after power is on.
>
>
> Booting the on-board eMMC image will work fine, the beaglebone appears
> on my network with SSH port available. With this android image the
> board won't show up on the network; Port scanning sees the device but
> no open ports available, also ping sometimes gives me Time out or
> unreachable. I'm not sure if it even booted or not. The user LEDs are
> flashing probably according to there usual pattern.
>
>
> I tried this  article but I get
> the same effect. As far as I know, the BB green and black are the same
> exact hardware which means the same should work on both, that's what
> BB website  is providing.
>
>
> What am I missing here? Thank you in advance.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/e6d24212-1606-4611-abb5-15a78710203a%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7d401644-a324-1819-92cf-33c08b3274d4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[Super Twang]

I’m currently looking for low-hanging fruit solutions to improve the BBB’s 
reliability at the moment and came across this.

This open source project aims to provide a generic API to many off-the-shelf 
UPS systems, usually via a serial/usb/ether connection.  I haven’t investigated 
this in depth yet, but it would appear that it gives you the software hooks to 
at least shut the bbb down when the mains go off, potentially monitoring 
battery levels down to a certain point first.  There’s still be some external 
logic needed to do a full solution (as described in the rest of this thread), 
but it could be an interesting component of a system.

http://networkupstools.org

They seem to support loads of OTS devices.

The debian metapackage name is ‘nut’ (for network ups tools), fwiw.

ST


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/B7E33771-0A0A-4BB1-925A-B3DA06A21EEF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Installing Android on BeagleBone Green

[Keith Conger]

The issue is the kernel in bbbandroid doesn't have the bbgreen device tree 
patches.  I was able to apply the patchs to kernel and run on the green 
with a LCD.

Keith

On Thursday, May 19, 2016 at 5:56:48 PM UTC-6, cpe.3...@gmail.com wrote:
>
>
> Hello all, 
>
>
> I downloaded the android image from here 
>  and I followed the usual 
> instructions using Win32DiskImager. I inserted the 16GB SD card to the 
> beaglebone and while holding down the S2 button that is next to the SD card 
> slot I applied power using an external power supply. I kept the button 
> pressed for few seconds after power is on.
>
>
> Booting the on-board eMMC image will work fine, the beaglebone appears on 
> my network with SSH port available. With this android image the board won't 
> show up on the network; Port scanning sees the device but no open ports 
> available, also ping sometimes gives me Time out or unreachable. I'm not 
> sure if it even booted or not. The user LEDs are flashing probably 
> according to there usual pattern.
>
>
> I tried this  article but I get 
> the same effect. As far as I know, the BB green and black are the same 
> exact hardware which means the same should work on both, that's what BB 
> website  is providing.
>
>
> What am I missing here? Thank you in advance.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/37e83bec-336b-4a18-95c3-862a18508edd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Hardware watchdog for BBB

[Lachlan Audas]

Yes.. it's been around some time,  I have used it on my UPS for desktop
computers.
worked well in that application.



On Thu, May 19, 2016 at 7:59 PM, Super Twang  wrote:

> I’m currently looking for low-hanging fruit solutions to improve the BBB’s
> reliability at the moment and came across this.
>
> This open source project aims to provide a generic API to many
> off-the-shelf UPS systems, usually via a serial/usb/ether connection.  I
> haven’t investigated this in depth yet, but it would appear that it gives
> you the software hooks to at least shut the bbb down when the mains go off,
> potentially monitoring battery levels down to a certain point first.
> There’s still be some external logic needed to do a full solution (as
> described in the rest of this thread), but it could be an interesting
> component of a system.
>
> http://networkupstools.org
>
> They seem to support loads of OTS devices.
>
> The debian metapackage name is ‘nut’ (for network ups tools), fwiw.
>
> ST
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/B7E33771-0A0A-4BB1-925A-B3DA06A21EEF%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAMkt-MsqqpNHkWTX9JjBRBhARVMKd-HAP3Y8cts0UC866wdQ4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: MT7601u 148f:7601 driver for Ubuntu 16.04 Xenial & HostAPD

[Jason Mumby]

3.8.13-bone79. I realise now USB0 is not the adapter. 

On Friday, May 20, 2016 at 1:25:44 AM UTC+12, RobertCNelson wrote:
>
> Which kernel?
>
> uname -r
> On May 18, 2016 11:53 PM, "Jason Mumby" > 
> wrote:
>
>> Not sure what is then ..
>>
>> ubuntu@arm:~/bin$ sudo ifconfig -a
>> eth0  Link encap:Ethernet  HWaddr 90:59:af:82:2e:09  
>>   inet addr:192.168.2.19  Bcast:192.168.2.255  Mask:255.255.255.0
>>   inet6 addr: fe80::9259:afff:fe82:2e09/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:11526 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:3236 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000 
>>   RX bytes:2134852 (2.1 MB)  TX bytes:434086 (434.0 KB)
>>   Interrupt:175 
>>
>>
>> loLink encap:Local Loopback  
>>   inet addr:127.0.0.1  Mask:255.0.0.0
>>   inet6 addr: ::1/128 Scope:Host
>>   UP LOOPBACK RUNNING  MTU:65536  Metric:1
>>   RX packets:170 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:170 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1 
>>   RX bytes:12610 (12.6 KB)  TX bytes:12610 (12.6 KB)
>>
>>
>> usb0  Link encap:Ethernet  HWaddr 90:59:af:82:2e:00  
>>   inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
>>   UP BROADCAST MULTICAST  MTU:1500  Metric:1
>>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000 
>>   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>>
>>
>> On Thursday, May 19, 2016 at 4:29:44 PM UTC+12, RobertCNelson wrote:
>>>
>>> usb0 is not your interface to mt7601u...
>>>
>>> sudo ifconfig -a
>>> On May 18, 2016 10:37 PM, "Jason Mumby"  wrote:
>>>
 ubuntu@arm:~$ hostapd -dd /etc/hostapd/hostapd.conf
 random: Trying to read entropy from /dev/random
 Configuration file: /etc/hostapd/hostapd.conf
 Could not read interface usb01 flags: No such device
 nl80211: Driver does not support authentication/association or connect 
 commands
 nl80211: deinit ifname=usb01 disabled_11b_rates=0
 nl80211: Remove monitor interface: refcount=0
 netlink: Operstate: ifindex=0 linkmode=0 (kernel-control), operstate=6 
 (IF_OPER_UP)
 Could not read interface usb01 flags: No such device
 nl80211: Set mode ifindex 0 iftype 2 (STATION)
 nl80211: Failed to set interface 0 to mode 2: -1 (Operation not 
 permitted)
 nl80211: Try mode change after setting interface down
 Could not read interface usb01 flags: No such device
 Could not read interface usb01 flags: No such device
 nl80211: Failed to set interface up after switching mode
 nl80211: Interface mode change to 2 from 0 failed
 nl80211 driver initialization failed.
 hostapd_interface_deinit_free(0x7f98e410)
 hostapd_interface_deinit_free: num_bss=1 conf->num_bss=1
 hostapd_interface_deinit(0x7f98e410)
 usb01: interface state UNINITIALIZED->DISABLED
 hostapd_bss_deinit: deinit bss usb01
 usb01: AP-DISABLED 
 hostapd_cleanup(hapd=0x7f98eee8 (usb01))
 hostapd_free_hapd_data: Interface usb01 wasn't started
 hostapd_interface_deinit_free: driver=(nil) drv_priv=(nil) -> 
 hapd_deinit
 hostapd_interface_free(0x7f98e410)
 hostapd_interface_free: free hapd 0x7f98eee8
 hostapd_cleanup_iface(0x7f98e410)
 hostapd_cleanup_iface_partial(0x7f98e410)
 hostapd_cleanup_iface: free iface=0x7f98e410
 ubuntu@arm:~$ 

 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google 
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to beagleboard...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/beagleboard/84788d1e-c743-4f9d-97cd-8b85fcef2a94%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/00bf0b87-bbe8-44ec-bc66-381cfd4cde4f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout