Guest guest Posted September 12, 2004 Report Share Posted September 12, 2004 Just want to throw my 20 cents worth in on this. It would be nice if all us frequency generator software developers could work on implementing the Atelier Robin F100 protocol in our designs. This would allow us to be able to provide more consistent results and better analysis, as well as portability of the treatment scripts between different hardware devices. This can be done with an F100 import module or interpreter built into your code. A better interface would be to build an XML parser (readily available) into your code and allow it to do most of the interpretation on XML-ready F100 scripts. We all need to think how best to achieve more consistent interfaces in order to provide more than ad-hoc results analysis. Regards, > Hi Rick, > I am currently working on a driver for my USB generator I am > attempting to build. What do you want to do with this generator? Did you > know that you can just use Hyperterminal to talk to your generator if it > connects to a comms port. Email me off list and I will see if i can help. > Regards > > Help freq programing > > > > Hi, > > I am looking for a consulting engineer/computer whiz to help me > > hook my TG1010 freq generator to be driven by a computer. The > > manual says it needs a RS232 remote command format or a > > GPIB remote format. The manual provides programming info. > > Thurnby has info on how do this but I am an expert in this area. If > > someone could help me through this that would be great. I will > > for the time involved. Please e-mail me if you have the ability to > > help me with this. > > Best, > > Rick B Quote Link to comment Share on other sites More sharing options...
Guest guest Posted September 12, 2004 Report Share Posted September 12, 2004 I think what the average user really wants is ONE device. There are so many high end function generators which have a built in display (even the cheapest models have one). This is the way almost all electronic instruments have been built for many years. To have to use a Palm PC along with another instrument is taking a step backwards, in my opinion. A 13 " color TV with on-screen display, programmable tuner, etc. cost as little as $80, and has far more parts than a programmable Rife generator. There must be a way to build a good one, with a display for under $700. Possibly modifying an existing function generator would make this possible. Bil Green PC 1000 Mammoth Lakes, CA 93546 Sunday, September 12, 2004, 9:48:07 AM, you wrote: d> Just want to throw my 20 cents worth in on this. It would be nice if d> all us frequency generator software developers could work on d> implementing the Atelier Robin F100 protocol in our designs. This d> would allow us to be able to provide more consistent results and d> better analysis, as well as portability of the treatment scripts d> between different hardware devices. This can be done with an F100 d> import module or interpreter built into your code. A better interface d> would be to build an XML parser (readily available) into your code d> and allow it to do most of the interpretation on XML-ready F100 d> scripts. d> We all need to think how best to achieve more consistent interfaces d> in order to provide more than ad-hoc results analysis. d> Regards, d> d> >> Hi Rick, >> I am currently working on a driver for my USB d> generator I am >> attempting to build. What do you want to do with this generator? d> Did you >> know that you can just use Hyperterminal to talk to your generator d> if it >> connects to a comms port. Email me off list and I will see if i can d> help. >> Regards >> >> Help freq programing >> >> >> > Hi, >> > I am looking for a consulting engineer/computer whiz to help me >> > hook my TG1010 freq generator to be driven by a computer. The >> > manual says it needs a RS232 remote command format or a >> > GPIB remote format. The manual provides programming info. >> > Thurnby has info on how do this but I am an expert in this area. d> If >> > someone could help me through this that would be great. I will >> > for the time involved. Please e-mail me if you have the ability to >> > help me with this. >> > Best, >> > Rick B Quote Link to comment Share on other sites More sharing options...
Guest guest Posted September 13, 2004 Report Share Posted September 13, 2004 Hi Dave, I just visited Altelier Robin's web site and viewed their web page on 3rd party software support for the F150 and F155. It would be good to be able to drive all the Altelier Robin frequency generators from one set of standard protocol. I'm not a C++ programmer so I'm not in the loop here but it is good to see Altelier Robin offering support for third party software. Getting Frex to generate scripts for Altelier Robin frequency generators would be easy to do so long as controls available gave access to all features like converge, fuzz, etc. which are required by all Rife researchers. 3rd party software developers wouldn't want to go to the trouble to build support for a FG if the most important features of it operation were not available. No one would use their software. If Altelier Robin released an ActiveX control (OCX library), then programmers of C++, Visual Basic and Delphi could use the same control to speak to the Altelier Robin FGs in a seemless way. This would also allow Altelier Robin's control to manage the coms/usb ports thus protecting the operation against any faulty commands that got sent to the FG by 3rd party developers and would make the interface hassle free for programmers. Alternatively, Frex could present a program output as it does for Freqgen, but designed so it can be copied and pasted directly into Altelier Robin's software for execution already in the format that the F100 requires. Just my 20 cents worth :-) Regards Ken Uzzell ----- Original Message ----- > Just want to throw my 20 cents worth in on this. It would be nice if > all us frequency generator software developers could work on > implementing the Atelier Robin F100 protocol in our designs. This > would allow us to be able to provide more consistent results and > better analysis, as well as portability of the treatment scripts > between different hardware devices. This can be done with an F100 > import module or interpreter built into your code. A better interface > would be to build an XML parser (readily available) into your code > and allow it to do most of the interpretation on XML-ready F100 > scripts. > > We all need to think how best to achieve more consistent interfaces > in order to provide more than ad-hoc results analysis. > > Regards, > Quote Link to comment Share on other sites More sharing options...
Guest guest Posted September 13, 2004 Report Share Posted September 13, 2004 Hi Ken, Some great ideas coming! I think an XML course wouldn't hurt the developer community which might better allow for the design of open interfaces that can manipulate and share data more effectively. Data and processes (used in a particular treatment protocol) can be better managed if these are stored in data structures. The communications between different layers of software and/or to hardware requires interfaces to be built. A hardware developer might build and publish an API (Application Programming Interface) for 3rd party development or they might not. Whatever functions are exposed in an API is up to the developer who often isn't highly motivated to allow 3rd parties complete access to the device or module. A programmatic API, like an OCX control, DLL or other, also requires significant knowledge of the 3rd party developer - changes in code on one side of the interface often necessitates changes on the other side, making interfaces more fragile and dependent on each other. Loosely coupled interfaces is a term used to describe the preferred mode of data passed between modules or an interface. In general, the more data dependencies there are between modules, the less robust is the interface. XML and its associated technologies is the modern day bridging technique, whereby data (and structures) as well as commands and arguments can be encapsulated into an XML structure and passed between modules and environments, quite independently of operating environment. Sorry for the lecture... Ken, if you or any others are keen to talk about this more and get more ideas and designs out there I'd be so pleased to be a part of this. I'm booked for the Rife conference in Seattle at the end of the month and am hoping to have some rough data models and programs that give a better indication of what we've been talking about, with GRID, F100 like protocol interfacing and frequency program design. I'd also like to collaborate on diagnostic/scanning issues even if it looks decidedly difficult. At this time I think the greatest benefit to the Rife community is for coordination and authentication of statistically valid quantities of results, which means data integrity and auditability (incl. processes) remains paramount. Looking forward to any feedback. Regards > Hi Dave, > > I just visited Altelier Robin's web site and viewed their web page on 3rd > party software support for the F150 and F155. > > It would be good to be able to drive all the Altelier Robin frequency > generators from one set of standard protocol. I'm not a C++ programmer so > I'm not in the loop here but it is good to see Altelier Robin offering > support for third party software. > > Getting Frex to generate scripts for Altelier Robin frequency generators > would be easy to do so long as controls available gave access to all > features like converge, fuzz, etc. which are required by all Rife > researchers. 3rd party software developers wouldn't want to go to the > trouble to build support for a FG if the most important features of it > operation were not available. No one would use their software. > > If Altelier Robin released an ActiveX control (OCX library), then > programmers of C++, Visual Basic and Delphi could use the same control to > speak to the Altelier Robin FGs in a seemless way. This would also allow > Altelier Robin's control to manage the coms/usb ports thus protecting the > operation against any faulty commands that got sent to the FG by 3rd party > developers and would make the interface hassle free for programmers. > > Alternatively, Frex could present a program output as it does for Freqgen, > but designed so it can be copied and pasted directly into Altelier Robin's > software for execution already in the format that the F100 requires. > > Just my 20 cents worth :-) > > Regards > Ken Uzzell > > > > > ----- Original Message ----- > From: " djs5916 " <djs@d...> > > > > Just want to throw my 20 cents worth in on this. It would be nice if > > all us frequency generator software developers could work on > > implementing the Atelier Robin F100 protocol in our designs. This > > would allow us to be able to provide more consistent results and > > better analysis, as well as portability of the treatment scripts > > between different hardware devices. This can be done with an F100 > > import module or interpreter built into your code. A better interface > > would be to build an XML parser (readily available) into your code > > and allow it to do most of the interpretation on XML-ready F100 > > scripts. > > > > We all need to think how best to achieve more consistent interfaces > > in order to provide more than ad-hoc results analysis. > > > > Regards, > > Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.