Cross talk

Hi,
I am trying to figure out cross-talk data for the different USRPs. I have seen some figures in this forum of ca -30 dB between Tx and Rx. Is this correct? In principle I am mostly interested in the coupling from Rx to Tx and -30 dB would be acceptable for my application, but I would like to have this confirmed.
BR,
Robert

This sounds in line with my experience. This post may help too.
I've tried things like transmitting with one USRP, and receiving on another...but it's not like you turn the Tx1/Rx1 chain 'off' if you just want to receive on the Rx2 path. So...you'll likely see the crosstalk anyway if you desire to transmit and receive on the same frequency.

Similar Messages

RE: local variable cross-talk?

Jeff
A global can be considered as a variable to the entire code, where lots of
different vi's can operate it. Locals only have any meaning within their
own vi, or instances of their own vi.
If anything writes to a particular global, whether in reenterent vi's or
not, it's available everywhere in the code.
What you were asking was about locals though. If a vi is non-renentrant
(i.e. as they come out of the box) then the values in the locals are vi
specific, no matter where the vi is, where it was last used, it retains the
data from it's last operation. If it is re-entrant, then the values in the
locals for each occurance of the vi are its own for EACH instance, i.e. just
like different locals in different vi's, it doesn't matter where else the vi
is used, the data held is that from the last operation of that specific
instance.
Simple way to demonstrate this. Make a vi that has one numeric control,
then code in +1 and get it to write to a local variable for that control.
Throw in an indicator to wire out the result of what is written to the local
for the control.
Then take this vi, put it in a for loop, then put another copy in the for
loop as well. Wire the indicators to the side of the for loop and create
indicator arrays for them. Get the loop to run 6 times say. Now try
running this with the vi in the for loop non-reentrant and then reenterrant.
One way the arrays will contain either all the odd no.s 1,3,5,7,9,11 and
then the other array 2,4,6,8,10,12 (don't know which array will be which,
depends which executes first in the for loop of this example). The other
way they will both be 1,2,3,4,5,6. In the first example, the same vi has
run 12 times, i.e. one copy of the vi which retains its info and is called
in many places and therefore only has one set of values, and the other with
two re-enterant copies where they have their information specific to that
instance of them i.e. effectively they are different vi's. Both ways are
useful, depends what you want.
If you're looking for a use for non-reenterant vi's then consider this:-
For instance. Supposing you get many things to try to write to a global
array of numbers, and you have two vi's one "A" writes to the first element
in the array and the other "B" writes to the second element. Because in LV
you have to read a global first and then write to it to perform a change,
these independant vi's "A" and "B" (be they re-enterant versions of the same
vi, or different vi's), can be performing the tasks simultaneously in the
code. I.e. "A" reads, "B" reads, "A" writes, and "B" writes over the top
with a modified version of what it read, and "A"'s changes are lost. This
is what's known as a "race condition" as "A" hadn't finished and "B" needed
to know what "A" was going to write before "B" performed "A" read. Try it,
hours of fun if you code this kind of thing in inadvertantly!
If the same vi is used, and is not re enterant, it can only run in one
instance at a time, hence two read / write operations cannot be performed
together, problem solved. Unless that gives you timing issues of course,
waiting for one to finish, to write the other......but that's another whole
can of worms.
cheers
Tim Price
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are confidential and may be legally
privileged. Access by any other party is unauthorised without the express
prior written permission of the sender. If you have received this e-mail in
error you may not copy, disclose to any third party or use the contents,
attachments or information in any way.
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jeffrey W Percival
Sent: 29 November 2001 21:12
To: [email protected]
Subject: Re: local variable cross-talk?
Another useful reply! What a great news group this is.
One last thing I wanted to ask about, though, is global vs. local. I see
you talk about globals, but in fact the variables in my subVI's were locals.
I can easily understand the behavior I observed accompanying the use of
global variables, But I guess the use of the word "local" stumped me.
Should I interpret "local" in LabVIEW's sense to mean "local to all
instances of this VI"? And global to mean "visible to all instances of this
VI as well as other VI's"?
-Jeff
Tim Price wrote:
This facility is actually very useful, for instances where you want to
encapsulate some code so that it can only run in one place at a time,
i.e.
global arrays that are written to in more than one place. This method
can
eradicate race conditions completely for example when used like this.
There
are multiple other uses as well.
However, using a vi as a module of code, to run in more than one
instance at
a time simultaneously, re-entrant is the way to go. Just make sure you
debug it first!!!
Remember though, just because a vi may be re-eneterant, doesn't mean
that
everything inside is; sub-vi's, Globals etc. The classic one I've seen
is
where people think that a re-enterant vi is talking to it's own copy of
any
Globals used within it, i.e. counters etc., where in actual fact of
course,
they are all using the same Globals.
Worth playing with a few examples to get familiar with it.
Tim Price
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) [email protected]
http://www.sal.wisc.edu/~jwp

Tim Price wrote:
Tim, thanks very much. I'll try the experiment you suggest.
Thanks for taking the time.
-Jeff
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) [email protected] http://www.sal.wisc.edu/~jwp

CROSS TALK - VIC FXO

Hi all,
I am facing the problem of cross call.
What happen is that,when someone is in a call and other people need to make a new call it dial to get voice tone, but it receive the cross talk (not the voice tone).
Someone known what could this?
The configuration is following:
voice-port 2/0
input gain 10
output attenuation 10
no vad
cptone BR
timeouts initial 4
timeouts call-disconnect 5
timeouts ringing 20
timeouts wait-release 5
timing sup-disconnect 1500
voice-port 2/1
input gain 10
output attenuation 10
no vad
cptone BR
timeouts initial 4
timeouts call-disconnect 5
timeouts ringing 20
timeouts wait-release 5
timing sup-disconnect 1500
Thanks

Please attach your entire running configurations. What version of IOS do you have? You may want to check CSCsg47594.

Cross talk in BNC 2090

Thanks for the information provided. I followed your advice by connecting
DGND1 with a wire to USER1 and DGND2 to USER2. But I still get cross talk.
It also puzzles with a fact that when I connect a signal source (from a
functional generator) to ACH1 but in fact the signals show up on the
Biobench screen as ACH0 as defined. So my hunch is that something wrong
happens to BNC 2090 or the PCI-MIO-16XE-50 board installed in the computer.
Would it be possible for me to send in the BNC2090 for a check? If so, what
are the procedures to follow.

We handle all repair requests over the phone. The procedure is as follows:
1. Go to www.ni.com/ask to create your own Service Request number (SR#). Choose the Phone NI option. Fill in the form with the appropriate information.
2. Call the support number that is given to you and enter in your SR#. You will be directed to an Applications Engineer (AE) that will assist you through the process. The AE will be able to answer any questions you may have about the repair process.
Have a great day.

Socket cross-talk.... multiplex read buffer?

i am using only 1 socket:
[pc #1] <--- socket ---> [pc #2]
concurrently:
the [pc #1] thread is sending input data to the [pc #2] thread.
and
the [pc #2] thread is reading input data from the [pc #1] thread.
this is of course, ok
the [pc #2] thread is sending results data to the [pc #1] thread
and
the [pc #1] thread is reading results data from the [pc #2] thread
some times "cross-talk" depending on timing
[pc #2] will read the output it sent to [pc #1] as if it
were input from [pc #1]
maybe multiplex the read buffer?
how to do that?
other ideas?

i am using only 1 socket:
[pc #1] <--- socket ---> [pc #2]You are using two sockets, one at each end. You are using one connection.
concurrently:Bilaterally, or in full-duplex mode:
the [pc #1] thread is sending input data to the [pc #2] thread.No it's not, it's sending data to the connection.
and the [pc #2] thread is reading input data from the [pc #1] thread.No, it's reading data from the connection.
this is of course, okIt's OK once you describe it correctly.
the [pc #2] thread is sending results data to the [pc #1] thread and the [pc #1] thread is reading results data from the [pc #2] threadNo, see above.
some times "cross-talk" depending on timing
[pc #2] will read the output it sent to [pc #1] as if itwere input from [pc #1]
TCP/IP doesn't do that. Any 'crosstalk' is due to a programming error on your part.
maybe multiplex the read buffer?Maybe fix your code?
other ideas?Maybe show us your code here?

Local variable cross-talk?

I have three VIs, call them A, B, and C. A uses C as a
subVI, and B uses C as a subVI.
Now, when A contains only C, I run A and everything is
fine. C has a boolean control and indicator, very simple.
When I place B in A's diagram, and leave it unwired, A no
longer behaves correctly. A can no longer control C's
boolean indicator. It's very strange.
Now, the instance of C within B is wired such that C's
boolean indicator is wired to False. In the instance of C
within A, the boolean indicator is wired to a switch. It
appears to me that just the presence of B within A causes
A's boolean indicator to be controlled by B.
Does this behavior ring a bell?
Jeffrey W Percival, Senior Scientist and Associate Director
Space Astronomy Labora
tory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
608-262-8686 (fax 608-263-0361) [email protected] http://www.sal.wisc.edu/~jwp

With B in A and not wired to anything, it will run as a parallel thread to whatever is happening in A. What runs first is not predictable without analyzing the VI. What probably is happening is that A passes the switch value to C then the parallel thread B runs and passes its value to C. So the A VI is doing what it is supposed to, it's just that the B VI is also doing what it is supposed to. Put a delay in A before it passes its value to C (making B run first), then see if B appears to no longer have control.
You might want to use the trace mode to see what it happening. Step through the program and watch what goes on.
Rob

Apparent cross-talk that is caused by software

I have several channels setup that test out find in MAX. When I acquire data on several channels(continuous acquisition to spreadsheet.vi), the signal for one of the channels appears noisy and the average is incorrect. If I acquire only one channel, the signal appears clean and is teh correct value. NO HARDWARE CHANGES during this process. I have tried differential, single referenced, and differential but still grounded and get the same kind of results. I am using a laptop card (AI-16X-50) with a SCB-68 accessory board which is grounded. Labview 7 with the latest MAX and drivers support and Windows 2k.
Thanks

This was posted in the NINews I recieved this AM.
6. My Laptop Reads a Floating Voltage from a Grounded Source
Laptop computers performing measurements can create a floating situation
similar to using a floating source. This article discusses measures you
can take to make sure your readings are accurate.
http://digital.ni.com/express.nsf/bycode/nn0104b21
That may help witht the noise on the channel.
Otherwise;
Is the device driven by that channel a high impeadance device?
Ben
Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Signal cross talk on pci 6014?

I am using a pci 6014 with a scc 68 wiring box two acquire two analog signals.
In AI 12, there is a amplified strain guage signal which spans 0-10v.
In AI 5, there is am amplified DC LVDT signal which spans -5 to +5V.
A respective ground from each sensor goes to the scc break out box.
When a sinusoidal signal is applied to the load cell, some of that signal is seen on the LVDT channel.
Yet, the LVDT has the core removed and is a large distance away from the project.
This strain guage signal shows up around 2V peak to peak on the lvdt channel.
Yet, if I stimulate the LVDT, I can see the signal clearly in both labview and on an oscilloscope.
None of the LVDT signal is seen on the load cell.
If i place an oscillosope on the LVDT output signal, the signal appears clean down to 20m regardless of strain guage stimulation.
It is only when plotting/charting in labview that Im seeing the strain signal on the lvdt channel.
Ill attach an example file from ni which is modified to read two channels at the same time, and the problem can be seen with this file.
I doublt the programming is the is the problem though.
Message Edited by jimmyinct3 on 11-13-2009 03:19 PM
Attachments:
Acq&Graph Voltage-Int Clk.vi ‏21 KB

Have you terminated non-connected signals with a 50 Ohm resistor?
I am not familiar with the 6014, but it might be an ADC with one converter, adding a terminated channel in between two channels might be a good idea if so.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Mailboxes cross-talk issues with Mountain Lion Mail Client

I have 4 mailboxes: two are setup as IMAP and two are setup as POP. Three of those are gmail accounts (one IMAP two POP) and one with IMAP is from a professional server.
The issue is that mail from the professional server with IMAP setup and mail from the gmail account with POP setup both forward copies to my gmail account with the IMAP setup.
I have no filters/rules in my gmail accounts or the mail account on the professional server.
I have no rules in mac MAIL.
Where should I look to solve this problem?
Thank you.

HI,
This might seem backward but let me explain.
Previous in iChat (version 4 through 6) it has been possible to set up a GoogleTalk account.
However compared to the versions on Mail with those ichat version the GoogleTalk servers have been much more "fussy" over the ID.
Mail has seemed to except using either/or @gmail.com or @googlemail.com version to get the Mail.
However iChat and later Messages beta seemed to be a lot more precise and the ID had to Match exactly as it appeared when you logged in to Google mail web page (or iGoogle) - Pull down your Account name.
As the System Preferences > Mail, Contacts and Calendars seems to pick up on Mail Account IDs , iChat/Messages IDs and other items I am sure it is possible that it is picking up an ID that works in Messages but now Mail is being a little more fussy.
After that I would check if Mail has a different password recorded.
Technically it is possible to set up an Account in Mail separate to the System Preferences > Mail, Contacts and Calendar pane (It gets added though).
One clue will be if the said System Preferences pane has two entries for Google.
From there I would open Keychain Access (Applications/Utilities) and check the password list for two or more entries for Google IDs and check the Password (Tick the Show Password Box and then enter your Login passwords an Allow once button to view)
9:29 PM Wednesday; July 25, 2012
Please, if posting Logs, do not post any Log info after the line "Binary Images for iChat"
 iMac 2.5Ghz 5i 2011 (Lion 10.7.2)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
"Limit the Logs to the Bits above Binary Images."  No, Seriously

New infinity connecton speed

After many years of strugglng with adsl our village has just had FTTC enabled. I am sure that there are no cross talk issues just yet and am wondering if my servcie is acceptable as it is nowhere near what I was expecting or told it may be when ordering.
The HH5, (not engineer fitted but plugged into master socket with flter) has been stable snce it was connected, and syncs just over 20/4 Mb/s
Could someone please look at the figures pasted below, partcularly the noise and attenuation.
Also the data sent/received seem much higher than I would have expected.
I am curious to find out why even the slowest quoted impacted speed is still half as much again as I am actually getting?
1. Product name: BT Home Hub
2. Serial number: +068543+NQ44611335
3. Firmware version: Software version 4.7.5.1.83.8.204 (Type A) Last updated 13/02/15
4. Board version: BT Hub 5A
5. DSL uptime: 3 days, 06:34:36
6. Data rate: 4798 / 21074
7. Maximum data rate: 5803 / 22429
8. Noise margin: 8.4 / 7.9
9. Line attenuation: 34.7 / 27.2
10. Signal attenuation: 33.6 / 23.0
11. Data sent/received: 3.7 GB / 9.3 GB
12. Broadband username: [email protected]
13. BT Wi-fi: No
14. 2.4 GHz Wireless network/SSID: xxxxxxx
15. 2.4 GHz Wireless connections: Enabled (802.11 b/g/n (up to 144 Mb/s))
16. 2.4 GHz Wireless security: WPA2
17. 2.4 GHz Wireless channel: Automatic (Smart Wireless)
18. 5 GHz Wireless network/SSID: xxxxxxx
19. 5 GHz Wireless connections: Enabled (802.11 a/n/ac (up to 1300 Mb/s))
20. 5 GHz Wireless security: WPA2
21. 5 GHz Wireless channel: Automatic (Smart Wireless)
22. Firewall: Default
23. MAC Address: 18:1e:78:10:87:22
24. Modulation: G.993.2 Annex B
25. Software variant: AA
26. Boot loader: 1.0.0
BT Home Hub 5 (Type A) | Software version 4.7.5.1.83.8.204 | Last updated 13/02/15
FTTC Range A (Clean)
64.4
45.3
18.5
11.9
Available
FTTC Range B (Impacted)
54.8
30.6
18
7.9
Available
ADSL Max
Up to 2
1.5 to 4.5
Available
Fixed Rate
2
Available

Hi jlpcld,
Welcome to the forum and thanks for posting, I'm sorry to see you're having issues with your connection. Those stats don't look great compared to the estimated speed even if it was an impacted line. If you need any help with this please use the 'contact the mods' link in my forum profile to send in your details. You can find the link by clicking on my username.
Thanks
Neil
BTCare Community Mod
If we have asked you to email us with your details, please make sure you are logged in to the forum, otherwise you will not be able to see our ‘Contact Us’ link within our profiles.
We are sorry but we are unable to deal with service/account queries via the private message(PM) function so please don't PM your account info, we need to deal with this via our email account :-)
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

New Infinity customer question.

Hi All, This is my first post so please be gentle...
I have recently ordered Infinity as it has just become available in my area, All websites I have visited state I will receive the full 40Mb download. I understand it may not be exactly 40Mb but how accurate are the predictions? I don't want to order and receive half the speed as it would not make sense for me to upgrade at all.
Thanks.
Solved!
Go to Solution.

The predictions are actually quite conservative. Have seen customers on here predicted 27 and got the full 40.
The reason being, is that the predictions are based on something like 90% of the ports in the FTTC being active. The more active circuits there are, the more cross talk interference there is. Cross talk WILL reduce the connection rate.
Vectoring technology is being worked on at the moment which will effectively negate cross talk but it's not needed at the moment
If you want to say thanks for a helpful answer,please click on the Ratings star on the left-hand side If the the reply answers your question then please mark as ’Mark as Accepted Solution’

Airport doesn't work when using a second monitor

My macbook pro, purchased mid-June, is exhibiting an odd problem. When nothing is plugged into the mini-displayport, everything is fine. If I plug my external monitor in, and the display is being mirrored, whether the lid is open or not, once again, everything works perfectly. Once I switch into extended display mode however, my wireless connection drops after a few minutes and refuses to reconnect.
It is definitely not a signal issue. The second I unplug the monitor, my wireless connection returns to normal even if I don't move the computer an inch.

Hello,
I have the exact same issue: whenever I am using my external display, my wireless connection with airport immediately stops. Same June 2009 macbook pro for me as well.
If I go down to the lowest resolution (640x480), I can get it to connect. The moment I unplug the external display, the wireless connection with airport is re-established.
This problem has been reported on the apple discussions forums by a few people. Someone mentioned that it could be electrical cross-talk between the graphics card and wireless card internally, one causing noise for the other.
Anyone have a solution? Or have the same problem?

SCXI-1321 Bad Chips and Function Calls

8-4-04
This message is intended for the PSE of the SCXI-1321 and that person�s manager. Please route it accordingly. I would appreciate a phone response to 8**-2**-2*** so that I might share some specific experiences.
To the managers of the SCXI product line,
I have used the SCXI-1121 with the SCXI 1321 for some time now, approximately 6 years. Our company generally uses them for full bridge pressure transducers and similar applications. I have some suggestions that would make them more saleable. I also believe that you will never know how many customers you have already lost on this product line, for the reasons given below.
1. For many years the shunt resistor on the 1321 has been vastly unusable. What SHOULD be possible is to command the shunt resistor through a Labview command, and then read the virtual channel to see the shunted value. That IS the purpose of the feature. What happens is that once you set the shunt command, then read the virtual channel, the very act of reading the channel UN-shunts the resistor. What you read is some value part way between, because the chip relay from Clare actually ramps open and closed, unlike a mechanical relay. If your timing loop to read the value is consistent, you will consistently read a BAD value. Several VI�s tried to command the shunt, then quickly read the virtual channel, then loop and do it again, and thought they had solved the problem. Further investigation showed that all that was really happening is that the readings appeared to be stable because of the fast loop time, but were actually mid-release of the shunt for all readings.
2. NI eventually starting saying �don�t use virtual channels with the shunt�. In fact, there is a channel string that starts with the word �shunt� that was recommended. The only problem with this is that the data that comes back is not scaled! Keep in mind that NI has been pushing �virtual channels� on users for many years as the way to do business, and so entire test stands are developed around them and MAX. Because we depend on MAX to do the scaling, how are we supposed to be able to read the data scaled? Does NI expect customers to duplicate the efforts of MAX for every virtual channel and scale it separately? Do I have to keep duplicate tracking of scaling information so that my virtual channels will work in the main code, but again elsewhere so that my calibration routine can read the data? This is messy, and for most customers, untenable.
3. I was told, literally, year after year and release after release, that the problem would be fixed in future versions of NI-DAQ. Each release proved that the problem was not resolved. I am sure that many customers were not repeat customers as they found the problems associated with using a simple shunt on the board. I myself needed this hardware due to the 1121/1321 parallel operation capability.
4. After years of trying to fight with the issues above, and what seemed like random problems with the shunting of channels, a second hardware related issue has finally been identified. See SRQ#600753 with Michelle Yagle. The Clare solid state relays installed on the 14 different 1321�s I bought ALL had the same defect. Imagine what this means for troubleshooting! You swap boards to try to troubleshoot, but they are all defective and so you falsely rule out the board, the problem didn�t resolve with a different board. The lot# 0027T12627 of chips covers a wide range of 1321 serial numbers (see my SRQ for details). That means this impacts a lot of potential customers. The part is rated by the manufacturer to 80C, 176F. This particular lot stops functioning as low as 96F! A great deal of testing with heat guns, shop air, and a thermocouple showed that all the chips in this lot fail somewhere between 96 and 110F, well below manufacturers specs or NI�s specs on the board. I also tested lot 98, from a board two years older, as well as new chips from lot 03, which both worked perfectly all the way up to 212F (100C).
Conclusions:
I believe that the people that have tried to use your 1321 have generally had a miserable time of it, unless they already do their own scaling (like some of the Alliance members do.) This is because the shunt feature is not compatible with virtual channels, because NI did not offer a reasonable fix for this problem over a four+ year period, and does NOT advertise this limitation when people are making hardware selections. Further, I believe there are many people that have boards with the same bad lot of chips on them that don�t know it. They may have elected to hardwire their own resistors after fighting with random problems (temperature related). They might have elected to hardwire their own resistors to get around the NI-DAQ limitation. They might not even use the shunt resistor. But one thing is certain: NI needs to clean up this board�s operation, make sure that customers of the serial numbers in my SRQ named above are notified of the bad chips, and fully test that the use of the relays is transparent to LV virtual channels in the future. People will not trust NI products with this type of problems, and will not buy the product again if all the features don�t work!
I have helped NI resolve similar issues with the SCXI-1126 years ago, which had a number of scaling issues in NI-DAQ (the board read great when you used 1k, 2k, 4k, 8k, etc. even ranges, but if you set a virtual channel to 0-2200, the readings were off.) I plotted the problem, documented it with my sales rep, and worked at length with tech support. The boards also had a lot of bad buffer amplifier chips that allowed cross talk between channels, causing a lot of other spurious problems. Those experiences were horribly frustrating, but I now buy the product with confidence. It took a lot of push on my part to convince NI there was a real underlying problem. This 1321 board is similar.
I want NI products to be the best they can be, as I have dedicated my career around them. Please take this feedback to heart, and contact me at 8**-2**-2*** to talk about these issues. Additionally, I am speaking at NI week this year and will be available for discussion. Contact me at the same number.
Sincerely,
Tim Jones
Test Equipment Design Engineer
Space Shuttle Program
Space, Land and Sea Enterprise, Hamilton Sundstrand

Tim
Thank you for your feedback for the SCXI-1321 terminal block.
I wanted to see if it would be possible for you to move your application to NI DAQmx, the new driver for DAQ and SCXI as of NI-DAQ 7.0. I have tested the shunt calibration using a SCXI-1121 and SCXI-1321 and it works as it should. There are two ways to do the shunt calibration with DAQmx.
The first is to use the Calibration feature in the DAQ Assistant. When creating a DAQmx Task in either MAX or LabVIEW, you can select the �Device� tab and click on the Calibration button. It will then ask you if you either want to do a null or shunt calibration, or both. It will then do the calibrations selected and save the values to the task.
The other option to measure the shunted value is to use the AI.B
ridge.ShuntCal.Enable property node in LabVIEW. By setting this property to True, the driver will enable the shunt for the current measurements. If you are taking a strain measurement, the value will be converted to strain.
We are currently looking into the issues you are seeing with the Clare relays to see if other users could be affected.
Brian Lewis
Signal Conditioning PSE
National Instruments

Time to upgrade to Full Frame

Team,  I currenlty own a 70D and a T3i with a bunch of EF-s lenses. My question is wether to upgrade to a couple of L lenses or upgrade to a full frame camera. Ideally I love to have a Mark III but a 6D is more realistic.   My budget is about $3500 I do real estate photography with some portrait side gigs on the side, no weddings or big projects.  Will it make sense to keep my 70D with some prime lenses for portrait photograpy? or go full frame is there much of a difference if i used a 70-200 2.8L lens on a 70D then a 6D?  your help and expertise is greatly appreciated.

Unless you want to get into really high end real estate photography, I'd suggest you stick with your 70D for now and start gradually changing your lens line-up, with a goal to build a system that will eventually allow you to add a full frame camera to use alongside the crop sensor camera. There are advantages and limitations with both sensor formats. I use both crop sensor and full frame cameras (a pair of 7D and a 5DII in my case, right now). I prefer the crop camera for sports/action and anything requiring longer telephoto lenses. And I like the full frame for landscape, architecture, portraiture and sometimes for macro work. One of the reasons I choose the full frame for portraiture is control over depth of field. Now, DoF is governed by lens focal length, working distance and lens aperture.... it doesn't actually change due to different sensor formats. However, in order to frame a subject the same way with a full frame camera, it's either necessary to use a longer focal length or move closer to the subject, or a little of both. Changing either distance or focal length will tend to render shallower depth of field. Conversely, full frame cameras can use smaller apertures before diffraction becomes an issue, so a FF also has some advantage for macro work or for landscape/architecture where great DoF is often wanted.  In generaly, there's a bit less lens selection for FF, though it's still quite extensive in the Canon system. This is because a FF camera can only use EF lenses, while your crop sensor 70D and my 7Ds can use both EF-S/crop-only and EF/full-frame-capable lenses. Also in general lenses for FF cameras will be larger, heavier and more expensive. It's most noticeable with telephotos, of course, but to some extent is true even with wide angle. IMO, on 70D a 70-200mm is a bit long for a lot of portraiture work. My most prefered lenses for portraits with a crop sensor camera are 50/1.4, 85/1.8 and 24-70/2.8. On full frame, my most frequently used portrait lenses are 85/1.8, 135/2, 70-200/4 and 70-200/2.8. Sure, there are times that wider and longer lenses can be useful for certain types of portraits. But these are what I use most often and feel are the most basic or "traditional" focal lengths for the purpose. Short telephotos generally render the most ideal perspective for portraits. Also, I mostly shoot candid portraits, not posed. Because that often means working with less than desirable backgrounds, I prefer larger aperture lenses that allow me the option to blur down distractions behind (and sometimes in front of) the subject. If shooting in studio or more posed at a planned location, with more control over the background and other elements, it would be different and large aperture lenses would be less necessary. Real estate photography work often calls for a wide angle and a lot of depth of field. With your crop camera, the EF-S 10-18mm you've got probably sees a lot of use. If you were shooting full frame, you'd probably want EF 16-35/2.8 or EF 16-35/4... or EF 11-24/2.8 (but that would use up most of your budget and not leave room to buy a camera to use it on). Tilt shift lenses such as the TS-E 17/4 and TS-E 24/3.5 II are also top choices for architectural photography. Compare size, weight and prices. Also, if you use filters a lot, some require larger (16-35/2.8 II uses 82mm) and the TS-E 17/4 and EF 11-24/2.8 both have stongly convex front elements that won't allow standard screw-in filters to be used at all. There aren't many truly wide lenses for crop cameras that are also FF compatible. The EF 11-24/2.8 is one of very few. The EF 14/2.8 II is another. So, to use the crop camera for wide angle shots, you'll probably want to keep at least one or two EF-S/crop only lenses. The EF-S 10-22mm is an older lens than the EF-S 10-18mm, but is a little better built and with more edge-to-edge image sharpness... it's one of the best ultrawides made by anyone... but costs about 2X as much. If it were me, I'd prefer the Canon EF-S 17-55/2.8 IS USM over the Sigma 17-70... but once again this is a "crop only" lens. For dual format purpose, one of the 16-35mm or the EF 17-40/4 might replace it better and be able to serve on both camera formats. I use a little longer 24-70 and 28-135 as my "walk around" or mid-range zooms.    6D is a nice camera and, compared to 70D, would be desirable for very large prints or for low light/high ISO shooting situations. That's because full frame images need less magnification for enlargement and use bigger pixel sites that capture more fine detail, both of which allow for bigger prints. Not that you'd notice much difference with 13x19 or smaller prints. And certainly you wouldn't be able to tell any difference at Internet resolutions if a lot of your stuff ends up on websites. Because the FF camera's 20MP sensor is so much less crowded than the 20MP crop sensor, there is less heat and less cross talk, making for cleaning or less noise in very high ISO images. The difference would be most noticealbe at ISO 1600 and above.   The 70D has a more sophisticated and versatile AF system, except that the 6D's can still manage to focus in one or two stops lower light (center point only). 70D has 19-point AF that's similar to original 7D, active matrix focus screen, and zone focus in addition to the all points/auto and single point/manual focus patterns offered by all Canon DSLRs. The 6D only offers the last to focus patterns, doesn't have zone, and it has a fixed (but interchangeable with a few types) focus screen. 70D's active matrix focus screen makes possible the camera's "grid on demand" feature that can be turned on or off via the menu, and which can be quite handy when shooting architecture inside or out. With 6D you can get similar grid in the viewfinder, but to do so would need need to swap out with a separately sold, accessory "D" type focus screen. In 70D all nineteen AF points are the more sensitive dual axis/cross type, with the center one enhanced for f2.8 and faster lenses. 6D's eleven AF points have only one dual axis/cross type... the center point... while all the others are single axis type. Either camera's AF system is probably more than adequate for what you say you shoot primarily. If you were shooting sports/action/wildlife/birds, the 70D's AF system would likely be more ideal, though... so I'd rate it as more versatile. The 6D's would be a better choice for low light work, though. 70D also has articulated LCD screen and built-in flash, while 6D has neither of those features. The 70D and 6D share batteries, chargers, memory and have mostly similar control layouts, always nice when using two different cameras interchangeably for various purposes. So, if it were me, I'd probably keep shooting with the 70D and work on lens upgrades first, then add the FF camera later. But that's just me. Your needs might be different and call for another approach. ***********
Alan Myers
San Jose, Calif., USA
"Walk softly and carry a big lens."
GEAR: 5DII, 7D(x2), 50D(x3), some other cameras, various lenses & accessories
FLICKR & EXPOSUREMANAGER

Five months of ongoing timeouts and connection loss

SE PA area. Problem started back in January with bursts of high ping times and timeouts on an old white Westell model with a WRT54g bridged to handle the routing. After several support calls a new Westell 6100 was sent but failed to resolve the intermittent problem. It seems to be aggravated by wet weather but also happens during dry periods just not as frequently. Around March tech support sent another Westell 6100 claiming the first one went bad. Problems continued intermittently as they've always been.
After a couple more calls to tech support they claimed the second Westell 6100 might be causing the problem and sent an Actiontec GT704WGB. Before getting the Actiontec installed our phone quit working (clicking noise and cross talk) but DSL continued to function with the same high pings and time outs randomly. This was last week and we were finally able to get a phone tech last Thursday (still had the Westell 6100 hooked up) to come to the house. Several hours prior to his arrival our phone started working and talking to the tech he said there was a line problem found and fixed.
While the tech was here, he put a splitter in line and ran a home run for the DSL to help us eliminate any possible filter issues and see if it would help with the intermittent DSL problems. I have also replaced the line from the NID inside with a new cat5e run. Yesterday (Friday) we had a bad rain storm lasting several hours (over 1.5in of rain) and the DSL has been garbage since.
I broke down today and pulled the Westell 6100 and my Linksys WRT54g out of the DSL line and finally installed the Actiontec GT704WGB and it's as bad or worse than ever. I've collected as much info as I can to try to shed some light on this if someone know how to interpret what the results are and can help, that would be awesome. I'm at my wits end with Indias tech support route and after 5 months I don't know what else to do.
Reverse traceroute during problem:
I x'd out my IP on the last hops.
06/2/2012 10pm
news-europe.giganews.com
1 vl201.gw2.ams.giganews.com (216.196.110.2) 0 ms 0 ms 0 ms
2 208.174.49.145 (208.174.49.145) 0 ms 0 ms 0 ms
3 cr2-tengig-0-5-1-0.frankfurtft3.savvis.net (204.70.207.209) 7 ms 9 ms 7 ms
4 cr2-ten-0-8-0-0.NewYork.savvis.net (204.70.195.22) 88 ms 88 ms 88 ms
5 er2-tengig-8-8.newyork.savvis.net (204.70.224.249) 87 ms 87 ms 87 ms
6 0.xe-9-2-0.BR2.NYC4.ALTER.NET (204.255.168.89) 94 ms 94 ms 94 ms
7 0.ae2.NY5030-BB-RTR2.verizon-gni.NET (152.63.18.74) 110 ms 96 ms 88 ms
8 ge-7-1-0-0.PHIL-CORE-RTR2.verizon-gni.net (130.81.20.139) 88 ms 88 ms 88 ms
9 A4-0-0-1723.PHIL-DSL-RTR7.verizon-gni.net (130.81.11.234) 88 ms 88 ms 88 ms
10 pool-xx-xx-xxx-xxx.phil.east.verizon.net (xx.xx.xx.xxx) 1736 ms 1714 ms 1593 ms
06/2/2012 10:03pm
news.giganews.com
1 gw1-g-vlan201.dca.giganews.com (216.196.98.4) 2 ms 0 ms 0 ms
2 g3-0.bb1.dca.giganews.com (216.196.96.62) 25 ms 54 ms 0 ms
3 xe-8-0-7.ar2.iad1.us.nlayer.net (69.31.10.97) 4 ms 1 ms 1 ms
4 TenGigE0-1-0-0.GW7.IAD8.ALTER.NET (152.179.50.73) 5 ms TenGigE0-2-4-0.GW7.IAD8.ALTER.NET (152.179.50.93) 0 ms TenGigE0-1-0-0.GW7.IAD8.ALTER.NET (152.179.50.73) 0 ms
5 0.xe-0-1-0.XL4.IAD8.ALTER.NET (152.63.37.93) 0 ms 0 ms 0 ms
6 0.ge-11-0-0.RES-BB-RTR2.verizon-gni.net (152.63.30.10) 0 ms 0.so-9-3-0.RES-BB-RTR2.verizon-gni.net (152.63.37.122) 0 ms 0.xe-15-1-0.RES-BB-RTR2.verizon-gni.NET (152.63.3.54) 0 ms
7 ge-7-1-0-0.PHIL-CORE-RTR2.verizon-gni.net (130.81.20.139) 7 ms 6 ms 6 ms
8 A4-0-0-1723.PHIL-DSL-RTR7.verizon-gni.net (130.81.11.234) 11 ms 9 ms 8 ms
9 pool-70-16-xxx-xxx.phil.east.verizon.net (70.16.xxx.xxx) 1206 ms 1339 ms 1661 ms
news-europe.giganews.com
1 vl201.gw2.ams.giganews.com (216.196.110.2) 0 ms 0 ms 0 ms
2 208.174.49.145 (208.174.49.145) 31 ms 0 ms 0 ms
3 cr2-tengig-0-5-1-0.frankfurtft3.savvis.net (204.70.207.209) 7 ms 7 ms 6 ms
4 cr2-ten-0-8-0-0.NewYork.savvis.net (204.70.195.22) 88 ms 88 ms 88 ms
5 er2-tengig-8-8.newyork.savvis.net (204.70.224.249) 87 ms 87 ms 87 ms
6 0.xe-9-2-0.BR2.NYC4.ALTER.NET (204.255.168.89) 94 ms 94 ms 94 ms
7 0.ae2.NY5030-BB-RTR2.verizon-gni.NET (152.63.18.74) 105 ms 88 ms 88 ms
8 ge-7-1-0-0.PHIL-CORE-RTR2.verizon-gni.net (130.81.20.139) 88 ms 90 ms 88 ms
9 A4-0-0-1723.PHIL-DSL-RTR7.verizon-gni.net (130.81.11.234) 88 ms 88 ms 88 ms
10 * * *
11 * * pool-70-16-xxx-xxx.phil.east.verizon.net (70.16.xxx.xxx) 1802 ms
Snippets of ping times to yahoo:
Reply from 98.139.183.24: bytes=32 time=55ms TTL=50
Reply from 98.139.183.24: bytes=32 time=55ms TTL=49
Reply from 98.139.183.24: bytes=32 time=72ms TTL=50
Reply from 98.139.183.24: bytes=32 time=76ms TTL=50
Reply from 98.139.183.24: bytes=32 time=66ms TTL=50
Reply from 98.139.183.24: bytes=32 time=52ms TTL=49
Reply from 98.139.183.24: bytes=32 time=94ms TTL=49
Reply from 98.139.183.24: bytes=32 time=137ms TTL=49
Reply from 98.139.183.24: bytes=32 time=40ms TTL=49
Reply from 98.139.183.24: bytes=32 time=420ms TTL=49
Reply from 98.139.183.24: bytes=32 time=973ms TTL=49
Reply from 98.139.183.24: bytes=32 time=1410ms TTL=49
Reply from 98.139.183.24: bytes=32 time=1995ms TTL=50
Reply from 98.139.183.24: bytes=32 time=3076ms TTL=49
Reply from 98.139.183.24: bytes=32 time=2058ms TTL=50
Reply from 98.139.183.24: bytes=32 time=114ms TTL=49
Reply from 98.139.183.24: bytes=32 time=54ms TTL=50
Reply from 98.139.183.24: bytes=32 time=55ms TTL=50
Reply from 98.139.183.24: bytes=32 time=43ms TTL=49
Reply from 98.139.183.24: bytes=32 time=68ms TTL=50
Reply from 98.139.183.24: bytes=32 time=141ms TTL=50
Reply from 98.139.183.24: bytes=32 time=69ms TTL=49
Reply from 98.139.183.24: bytes=32 time=52ms TTL=50
Reply from 98.139.183.24: bytes=32 time=56ms TTL=50
Reply from 98.139.183.24: bytes=32 time=309ms TTL=50
TRANSCEIVER STATS:
Inside house (10pm 06/2/2012) around the time of the above traceroutes and ping snips.
DSL Status
VPI: 0
VCI: 35
DSL Mode Setting: Auto
DSL Negotiated Mode: G.DMT
Connection Status: ShowTime
Speed (down/up): 1792/448
ATM QoS class:    UBR
Output Power (Downstream/Upstream): 11.9/17.3 dBm
Attainable Rate (Downstream/Upstream): 8352/1064 Kbps
HEC Errors (Downstream/Upstream): 1/0
OCD Errors (Downstream/Upstream): 0/0
LCD Errors (Downstream/Upstream): 0/0
SNR Margin (Downstream/Upstream): 29.8/22.0 dB
Attenuation (Downstream/Upstream): 49.5/24.0 dB
At NID (tested a couple hours prior to inside test above)
DSL Status
VPI: 0
VCI: 35
DSL Mode Setting: Auto
DSL Negotiated Mode: G.DMT
Connection Status: ShowTime
Speed (down/up): 1792/448
ATM QoS class:    UBR
Output Power (Downstream/Upstream): 11.9/16.8 dBm
Attainable Rate (Downstream/Upstream): 8160/1052 Kbps
HEC Errors (Downstream/Upstream): 1/0
OCD Errors (Downstream/Upstream): 0/0
LCD Errors (Downstream/Upstream): 0/0
SNR Margin (Downstream/Upstream): 29.8/22.0 dB
Attenuation (Downstream/Upstream): 49.5/24.0 dB

Ah.. I was hoping you'd stop by and chime in. Thanks! I spent a couple of evenings browsing the forums looking at others' issues and was always impressed with not only your knowledge but your willingness and consistent help to many who post up with issues. I'm gonna have to give you a Kudos on this as it's the best I can do and people such as yourself and several of the other regular "assistees" I've seen help here are what really make these forums/communities the great resource that they are.
As I have a technical background in electronics and electro-mechanical I was able to blow through a lot of good information on what to check and get all my potential infrastructure issues on my side covered before going any farther (replacing my old lines with new cat5 and new jacks, getting the tech to put a splitter in and run a home run for the DSL line). But I don't have much knowledge in the telecommunications end and DSL. Your info helped a lot with shedding some more light on that as well as reading other posts.
I saw the Redback router in the reverser trace and had gathered from other reading that they're older units. I have no idea what if any upgrades will be done at my CO. I am in fact fed from a CO and that fits in with my attenuation numbers as I'm about 2 miles away. From the numbers I estimate between 12-13000 feet on the wire.
A short update since Sunday. Yesterday my wife received a call from a US based tech from the Chronic Intermittency team (I think that's what she called them) and after looking at the line the nice lady was a bit perplexed as I was as the numbers look so good on the line. She was able to determine after several steps with my wife, that we might just be saturating the 1.7Mb we were provisioned at and the modem was just giving up the ghost and timing out eventually. She opened the pipe up to 3Mb and it's gotten MUCH better since yesterday. While it tightened us up quite a bit on the Margin (I was a little surprised at how much the Margin dropped with only doubling the rate) it appears 5Mbps would easily be doable barring no other line issues. What I was most favorably impressed with though was that the nice lady promised to call back and stay with this issue until resolved. She's off for a couple of days which will give us some time to see how much better this one change has improved things but she did call twice yesterday (a call back followup after the original call and bumping up the provisioning to see if she was on the right track). That certainly helped boost my confidence level with Verizon's support a bit...
New transceiver stats 6/4/12 actual stats were taken 6/5 with 54hrs uptime.
DSL Status
VPI:   0
VCI:   35
DSL Mode Setting: Auto
DSL Negotiated Mode:   G.DMT
Connection Status:   Showtime
Speed (down/up):   3360/832
ATM QoS class:   UBR
Output Power (Downstream/Upstream):   11.9 / 11.6 dBm
Attainable Rate (Downstream/Upstream):   8320 / 932 Kbps
HEC Errors (Downstream/Upstream): 522 / 0
OCD Errors (Downstream/Upstream): 0 / 0
LCD Errors (Downstream/Upstream): 0 / 0
SNR Margin (Downstream/Upstream): 17.1 / 9.0
Attenuation (Downstream/Upstream): 49.5 / 24.0
I also found it interesting that the upstream output power dropped so much. It appears that modem was getting a workout at 400Kbps. Downstream held the same.
I'm not ready to mark this resolved yet but it does appear the lady was correct in her assumption that we were saturating the connection as a primary root cause. Interesting...
What I still find a bit of a puzzle is our online habits haven't changed (always run virus/trojan protection as that was one item the tech queried due to the activity she was seeing based on what my wife had running at the time) and yet this didn't crop up until the beginning of this year. We primarily run 2 desktop systems and I use a laptop wirelessly occasionally (yes, I did kill the wireless on the router for a day in troubleshooting). My usage is primarily browsing and email and my browsing is mostly forums and finance based so not a lot of high bandwidth usage there. The wife does have an online game she's played for years and does use Skype and Teamspeak during her gaming, but her gaming habits/use hasn't changed over the years either. I do run the Network Meter Gadget on Windows 7 on all PCs so we can monitor our rate dynamically but it's hard to aggregate that info when we're both online to see the total bandwidth we're pushing. I've watched her sessions as well as monitoring mine and she was by no means in constant saturation. I was surprised at the constant "chatter" Skype puts on the line even with no ongoing conversations. I suspect some congestion at the DSLAM might be in play here as well. We'll see how it all shakes out in the end. I'd certainly like to get the bump to 5Mbps if it's doable and think that might just buy us a bit more life until we finally have to cave to Fios.

Cross talk

Similar Messages

Maybe you are looking for