Help: Q2686H and Q24 plus design dilemna


#1

Hello All,

We have used Q24 plus to design and develop a GSM Telemetry solution. Due to severe resource problems we’ve somehow designed this solution in a kind a reverse way. That means, instead using the Q24 plus ARM7 CPU power we’ve used PIC16F877A micro controller to interface (RS-232, RS-485 etc) with the Q24 plus module. We’ve used EEPROM 24C512 for storage instead of using Q24 plus flash memory (I think it’s 1 MB or something which is available). Code written in Assembly.

Now I’ve a Q2686H sample, we would like to go ahead (new features) with GSM/GPRS Telemetry solution. The questions are:

(a) Will it take lot of time for us to develop a proper Design (using Q2686H pin outs, thus eliminating PIC16F877A) - it would be kind of right from scratch almost!

It took us 3-4 months to come out with a Q24 plus based proper design & solution (even though reversed) - design from scratch, schematics, fab, firmware and software application to capture the relayed Telemetry GSM data.

If the Answer for (a) is not advisable to pursue in terms of time & cost, then:

b) Reusability: How to convert this Assemble code into C (Q24 plus to Q2686H; what tools to be used; we used only Mircrochip IDE for the programming with Q24 plus).

©Are there are any Application notes or reference designs based on Q2686H? (which could help me to save time)

Note: Local Wavecom dealer is hopeless in terms of tech support or component supplies! We don’t have good resource to speed up the design and coding. We are in kind of catch-22 situation (in soup) by investing lot of money but still we are not yet there (market ready product).

Please answer my questions. Thank you very much in advance.

sukhoi47


#2

My opionions:

a) It obviously depends very much one what your product does. Also keep in mind that Wavecom OpenAT is not always suitable for doing very fast realtime operations. For this very reason our design uses both a dsPIC33 and a Wavecom WMP100 microprocessor. The dsPIC does all the realtime stuff, I/O and interfaceto Zigbee etc. The Wavecom micro does the communications and GPS stuff. The two communicates via SPI. It works well and we sort of had the best of both world in terms of ease of development. Without the Microchip in-circuit debugging it would have been very difficult because Wavecom does not have the same. But three of four months sounds like a realistic timeframe.

b) I think you will most probably need to re-write it. But that shouldn’t be a major deal if you are just going to re-write assember into C for exactly the same hardware.

c) I leave this answer for someone that uses the Q2686H. We use only the WMP series.


#3

Thanks for the response. Product is a machine to machine industrial solution (15 clients relays the data parameters via a Master modem, pulled by the application running on the PC which displays the data parameters). We don’t know anything about OpenAT, again it will be a bottleneck for us to get hands on that. Yes, we’ve achieved it almost 4 months for the solution using Q24 plus (that too because of resource issues, else it would have been more faster). Do you mean to say what we’ve done (using PIC with Q24 plus) is right approach? Should we follow the same approach for Q2686H too?

Yes, we’ve thought so on re-write but it will take good time. Something like 1 month effort or so incorporating new features. And there is validation tests etc. So by no means I can convert the existing Q24 plus Assembly code (into C) for Q2686H?

Hope someone answers :frowning:


#4

In our case we did not have much of choice. The Wavecom processor alone would not have been able to do everything we needed. I presume you used only standard AT command calls. This excludes a lot of usefull functionality which only exists if you use WIP and ADL, which is only possible if you actually run some code on the Wavecom device itself as well. So I think have the additional processor can be usefull, but you should consider splitting code between the two.

When we design our next product, we will do the same again. The cost of the additional PIC microcontroller did not have a big impact and it gave us a lot of advantages. One of the more obvious ones is that you can use the external processor as a watchdog circuit for the Wavecom device.

A good approach might be to define the basic product and then get an external contractor who knows OpenAT very well to do it as a contract job. You should specify that you get the C source code so that you can use it as basis to add your own final touches and future enhancements. It will go a long way into fast tracking you to get up to speed if you have working source code as basis to start from. I know a contracter that we used when we started and if you give me a way to contact you I can give you his contact details. I can strongly recommend his services.

To tell you the truth, you can probably use examples for any of the Wavecom decices. 95% of the code is generic and will run on any of the devices, and it will not be too diffcult to adapt to you specific device. If you install OpenAT it comes with quite a lot of sample code.