Messages posted by: Rick

Hello Everyone,

Okay, perhaps a certain amount of Rick-bashing was to be expected, since I was busy traveling while the company was running over-capacity.
I've been out of the country for 4 months, traveling overseas, which has made things a challenge at times to keep up and remotely manage things.

Here's how we are improving things, to usher in the new year:
1) We've made additional capital equipment investments during the past two weeks, which will greatly speed up production and reduce our dependency on contracting out larger jobs.
2) We are moving to a new office in Dallas which will also give us additional capacity
3) We are adding an additional full-time person to start 1st week January

We will also have a 2-week company holiday, from December 22 to January 5, in which we'll move into and setup our new office.

Hopefully this will alleviate some of the growing pains we've been experiencing, so we can provide improved service to all.

We very much appreciate all your business, and are honored to be of service to you.
Thank you! God Bless, and Happy Holidays to all.

Hi ElectronKing,

The RFM69HW-915 is in stock, and available both on eBay and on the website.
The new MiniWireless units are also in stock, I just need to update the website, database and all...

RE: Concerning the MiniWirelessMega ---

Here's the update for the 1284 miniWireless Mega series...
We now have a mega board, that we have been evaluating and testing, and things are looking very good to go forward with production.

Features:
- RTC with support 2-types of SuperCap
- Memory 128Mb standard (up to 256Mb)
- Mosfet Power Control
- ATmega1284p, 16Mhz
- LDO Power regulation
- SMA Connector
- Support for RFM69HW, W on bottomside (more to come)
- Pinout compatible with miniWireless - for sharing of shields
- modern bootloader, but may update with another on release (for full support for wireless programming)

Price TBD (perhaps about $3 more than current miniwireless)

Here's an image of one of our first prototypes:

Greetings,
I've not seen this type of problem, and I have shared the SPI bus with many devices on quite a few projects.
Unfortunately I don't have one of those displays, and thus not in a position to reproduce the problem.
Not having seen the schematic or code involved, I can't really see the whole picture, but here are a few thoughts:---
Is the SPI mode and clock within specification for the display?
Is there an SPI device select overlap?
Is operational voltage within spec on devices involved?
When you're done with one device, what do you do with the spi select for that device? is it deasserted or left floating?
Does the problem go away if you insert a delay between bus usage?
Of course my assumption here is that the library for the display is bug free?
Do you happen to have a scope and/or logic analyzer to view SPI bus activity during operation?
Not sure if this helps, but there has been some buzz about SPI, perhaps check out the post concerning simultaneous SPI usage.
http://forum.anarduino.com/posts/list/18.page
Also there is a hackaday blurb:
http://hackaday.com/2014/08/01/arduino-spi-library-gains-transaction-support/
perhaps this along with a few searches can lead to an elegant solution.

Please let us know how things work out, as this insight could be useful for others.
Thank you.

Best Regards,
Rick

OMG..

yes of course 300nA is correct. I edited my post accordingly. Well, I must not have configured this properly, as this circuit should get below 50nA per board--will have to re-examine.

It's not voodoo at all, but rather simple, and will make total sense when you see it. I'll get around to posting the schematic once these things start shipping.
Will follow-up again with more thorough test later, as I have better test equipment in the office.

I really appreciate your post, although it's quite embarrassing having posted such a ridiculously obvious error...

Yeah, certainly some broken logic their number scheme, and also in their product roadmap.. Originally they meant it to be 'H' high power version of "CW", however the pinout differs. As apposed to the W/HW having same module footprint AND pinout. Unfortunately and frustratingly, the HCW is meant to be an upgrade/migration path from the 22B (however, there are some subtle issues in doing so---so Hope put together an APP note of sorts for this. Only works however for ONE of the two more popular arduino interconnect schemes). The CW has same footprint as the RFM12B and is footprint compatible without issues seen when going 22B->69HCW. I suggested to HopeRF early on in the very beginning that they do similar to what was done for the W/HW by having at least the same pinout.

I will also confirm as already posted, the HW and HCW are 100% software compatible and they differ ONLY in footprint/pinout. Personally I prefer the HCW as it has smaller physical size, but the HW is by far the more popular.

Cheers,
-Rick

Hello everyone,

Okay, here's an update on low power testing of these these new series. Well, I've stated the quiescent current should be less than 50nA.
I wrote code to cycle the new MW to run 5sec on / hibernate, and hooked 4 boards in parallel and measured.
The first result shows combined current of 1.2uA for ALL four in hibernation together, which is about 300nA per board---still way too high.
so I'm going to review everything and do further testing, as in theory I believe this circuit should get down under 50nA.
So it looks like the product is finally about ready to go. Here's a view one of the panels hot out of the oven.
Next week I will begin formally offering these for sale.

Three products shown above are:
1) TLogger (now with SMA per another customer suggestion)
2) MiniWireless-HW (for RFM69W and HW series)
3) MiniWireless-BP (for RFM23BP series)
LoRa and several others now in the works as well...

Best Regards,
Rick

Hello everyone! Okay, it's time for a long overdue update...

Our first three product types of the low power series will be ready to begin testing this Wednesday. After a couple days of testing, we'll announce and make available for purchase. So we should have them publicly available for purchase starting next week.

My apologies for the delay, as I've been traveling overseas for the past two months, which has caused a bit of a schedule slip on things.

Best Regards,
Rick

Hi Nick,
Thanks for posting.
How was the board damaged?
We do 100% QA and test of these boards prior to shipping, and we guarantee all of our products against DOA.
Please send me email if this was damaged in transit, I'd like to hear about it and get you a replacement.
Best Regards,
-Rick

Hi Charly86,
Thanks for your comments, and I empathize with you on this.
Several times early on, I have asked Hope to clarify these things, but they simply moved forward with a mind of their own. I should have made a wiki page on these things to further clarify, so therefore I will take responsibility and suggest the following: Please send the radios back to me for a full refund.
Furthermore, I will also give you a decent discount on your next purchase to help compensate for your added shipping cost on sending them back.
Best Regards,
Rick

Hello, and thank you for your post and concern. Well, it's easier for me to be transparent and just share the issues with y'all...

At first we always had several hundred extra Mini's and MiniWireless in stock, which of course worked out great. Then demand got heavy and we allowed ourselves to get into a JIT type of manufacturing mode of operation, and still worked well as our process is smooth and streamlined. Still worked great, because we could still easily meet demand. However, over the weekend our Technician was doing a large production load to meet the demands of all the weekend purchases and enough for the coming weeks. The initial large batch of panels moving through reflow got literally fried and we lost the entire batch and the ability to produce. Fortunately we were still able to meet the majority of Monday's shipments, but no all. We then immediately refunded all the impacted customer orders. Having ran out of most the popular MW versions, it seemed easier to just shutdown our manufacturing and just retool--rather than fumble along with depleted remaining stocks and answering the endless streaming questions of when...

So, a few more knocks from the school of same...but at least, an important lesson learned. Don't use antiquated machinery---unless with redundancy. Anyway, we're retooling and investing in better equipment, and plan to set up dual lines, so we are never at risk of this in future. We sincerely apologize to all our valued customers, and look forward to serving you in a much enhanced capacity in the very near future. We have many more product lines to add, and we're looking forward to an exciting second half of 2014 and following...

Thanks for enduring the rant, and best regards to all,
-Rick

edringel wrote:Hi,
New to this product, would appreciate any advice or direction about an antenna for the 400 MHz series radios. Looks like a piece of wire would do, but if anyone has specific suggestions about length and/or geometry I would appreciate it. Thanks in advance.

Cheers.

Ed

A simple monopole antenna should work fine.
Many suggest for 433Mhz, you can use #20 guage wire of length 17.3cm (6.81 in).

Did an internet search just now, and found on jeelabs forum, a list of calculated values--which look reasonable:
433 1/4 wave = 164.7mm
433 1/2 wave = 329.4mm
433 full wave = 692.7mm

868 1/4 wave = 82.2mm
868 1/2 wave = 164.3mm
868 full wave = 345.5mm

915 1/4 wave = 77.9mm
915 1/2 wave = 155.9mm
915 full wave = 327.8mm

Anyone else who would like to digress and add to this, you're more than welcome.
There's certainly a plethora of info out there...

Hi Sensorhub,

Thanks, I appreciate the feedback about the tactile...that makes two of us.
Initially I felt the same way, but then became accustomed to it, and can now sense engagement from fingertip and thus no-longer have to overcompensate.
I've removed the tactile all together on some of the products as you can see in this original post.

Haven't set pricing yet, but it will be close as possible to the current MW line.

Hi Grant,

A very loooong time, but how long depends on which radio is used, power transmit level, length of message packet, data transmit rate, and what else you're doing during wake state. With such a low quiescent, it makes the consideration of discharge during hibernation, almost negligible. I'm very excited about this, and I plan to consume a large number of these devices for my own projects as well.
All the best...
-Rick

grantsmith wrote:Hi,

Looking at http://www.anarduino.com/miniwireless/#schematic I deduce that the following pins are used by the internal electronics, assuming RTC, Radio and Memory are all being used by a sketch:

RTC: D3, A4, A5
Memory: D5, D11, D12, D13
Radio: D2, D10, D11, D12, D13

Questions:

1. Why is there a pull-up on D3 ? Can I use D3 and Interrupt 1 ?
2. If I don't use RTC, Memory or Radio (or any combination) in my sketch, does that mean the pins used above for those two are accessible ? Or will there be unpredictable side-effects ?
3. The schematic is for RFM12B - Has anything changed for the LoRa Miniwireless modules ?
4. If I power from 3.3V into VCC (NOT VIN), does this completely bypass the voltage regulator ? I want to create a low power/sleeping battery powered situation where the module is woken up by an interrupt on pin D3, without the inefficiencies of a voltage regulator in the way.

Thanks,
-Grant.

Hi Grant, here's my .02

Yes those are the pins in use.

1 - The schematic shown is the for the MW-12 with RFM12B in which interrupt enable is active LOW, so I added a pullup to differentiate between states even when the radio int pin is high impedance.
The pullup could be removed for other radio types, like rfm69 for example, whose state is opposite that of the 12b. Thanks, good point.
2 - If you don't want the RTC or MEM, then you can order the MW without these for a lot less. Otherwise, here are my comments: if the radio is put in a sleep state, then you should be able to use D2 and D10 without issues. As for the memory, you might have problems using D5 for other things during SPI bus operation.
3 - Yes, the FTDI 6-pin connect Power comes into VIN (and not VCC). In fact all MW have this as VIN input instead of VCC--with the exception of the first MW, which is the 12B version. When the current stock runs out, I'll do another pass on it, making it VIN as well.
4 - Yes, it bypasses it if you put 3.3V directly into VCC, and this is the way I previously used it as well. However--> As for low power, I would suggest going with our new MW Low Power Series. It features extremely low quiescent of < 50nA, which is pretty much best on the market. I'm in production now, so they should be available soon... Here's a teaser: http://forum.anarduino.com/posts/list/15.page

Thanks for your post...
Cheers,
-Rick

Hi,

Didn't realize about the attachment issue, thanks for pointing it out.

Here's a link for the file: http://www.anarduino.com/docs/Time.zip

Cheers..

Hi Grant,
Yes, you can apply 3.3V to VCC, and 500mA sufficiently covers component requirements. With the STRONG assumption however, that there is good quality and voltage stability from your wall charger.
A better choice might be 5V on the VIN input pin.

Cheers. -rick

Interesting and informative. Thank you for your feedback in this regard.

Thanks SadE for your follow-up.

I just contacted HopeRF directly concerning this. They are not aware of any such issue, and no customers have inquired about same.
I like to give everyone the benefit of the doubt, and thus also willing to accept there could be an issue. All things considered, and until proven otherwise, it seems the RFM69 remains cleared for continued use.

However, I do remain quite curious of the conditions and remedy surrounding Paul's claim, and am certainly interested in any forthcoming improvements he might have on the SPI library. If things weren't so busy, I would definitely succumb to further experimentation myself. I hope to hear of the results from Paul's exploration in this, and to reach finality and consensus with others.

Thank you. The new generation of MiniWireless use a different RTC, but done precisely and exactly to specification. Details of which will be posted soon, along with formal announcement.

Hi SadE,
It was quite some time ago that I came across the Time library, so I don't recall where it came from. However, the author and credits would be preserved appropriately in the source files. I'll also add a link to the miniwireless webpage.
Cheers,
-Rick

Thanks Charly,
I look forward to sharing all these things in detail very soon. I just made a few enhancements from design in the pics previous posted. So I am heading into volume production with these new ones. In a couple weeks I'm going to post it and make it available for sale. We believe this is going to be a major thing for the market, so I want make sure we have at least 1K units stocked and ready for the announcement.

I'm curious about your developments as well, and very much interested in collaborating more with you soon.

Thank you for your participation in our forum.
Cheers,
-Rick

Hi Paul,
Thanks for the heads up. We're always interested in improving things for our customers. Steve mentioned to me about your blog concerning this, and I also looked it over. I'd be interested in finding out more.
We have thousands of devices out there that use RFM69 with the spansion memory, and also products which share the SPI bus with other types of devices(e.g. accel,gps,bus expanders, and even multiple SPI memory chips. These all seem to play well together, and we have not noticed the issue you have seen. Whether this is an SPI library issue, or even a radio issue, please keep me in the loop on this, and feel free to contact me anytime. For what's it worth, no other customer has expressed to us the issue you have seen on the RFM69. I'm also contacting HopeRF factory engineering to see if they are aware of such a thing. If they have anything useful and relevant to offer, I will certainly follow-up with an additional post.
Best Regards,
-Rick

Hi Bryscus,

Thanks for your Post.
I don't see how this would be possible, because in our internal process, ALL miniwireless boards without exception, are both bootloaded and programmed with a test routine prior to shipping. The boards then MUST pass QA test which includes RTC coding with sleep/interrupt processing, and Memory read/write tests before they are allowed move over to be packaged or joined with a radio. After reading your post, I called our Technician responsible for this, and he concurred as well, that there is strict adherence to testing procedure. The importance of this was further reinforced in my communication with him just now.
We work hard to do our best for customers in both quality and service, and we are always open to learn and improve. Any comments, criticisms, complements, and such, are welcomed.

All the best...
-Rick

Hi Charly86,

Thanks for your post, and excellent contribution.

I looked at your link just now, and it certainly seems worthwhile to checkout.
I've also noticed the TH02 sensor has a high degree of functional compatibility with the siLabs si7005.

Cheers,
-Rick